DEV Community: MakeInterview

I open-sourced the counting tool, and it immediately caught two of its own bugs

MakeInterview — Fri, 02 Oct 2026 00:10:11 +0000

I published a count a while back: the King James Bible says "fear not" 62 times, not the 365 the wall art claims. Then I turned the counting code into a small open-source tool — and the first thing it did was prove itself wrong.

Two bugs, both silent

Bug one: substrings. A naive search for fear also matches fearful, fearfulness, and God-fearing. That inflates a raw count by roughly 15% and looks completely reasonable on the screen.

Bug two: punctuation as glue. I normalised away punctuation so fear not. and fear not would match. But stripping punctuation also turns 1 Peter 2:18 —

Servants, be subject to your masters with all fear; not only to the good and gentle...

— into the string ...all fear not only..., which contains the phrase "fear not" even though the verse does not say it. One false positive, from a semicolon.

Neither bug threw an error. Both produced a plausible number. I only caught them because the tool runs over the whole corpus and asserts its output against a published per-verse audit trail.

Why I ship the corpus, not just the number

The repo includes the full KJV (31,102 verses) and the Chinese Union Version (31,100 verses), plus a test that re-derives every published count:

node test.mjs
# ok — tool and audit trail agree over the full KJV (31,102 v) and CUV (31,100 v)

A count with a stated rule can be checked, corrected, and cited. A count without one is a rumor with a decimal point. The rule here is explicit: whole words not substrings, whitespace joins words and punctuation never does, verses for phrase claims and occurrences for word claims, and every rule reported separately instead of silently merged.

The takeaway for anyone publishing a number

If you publish a number, publish the rule that produced it next to the number, and publish the rows so someone can diff your work instead of trusting it. The two bugs above are not exotic. They are what happens when a number travels without its method.

Valve's public achievement endpoint is an underrated analytics feed

MakeInterview — Thu, 01 Oct 2026 11:47:04 +0000

Valve's public achievement endpoint is an underrated analytics feed — here's its shape

While building a small bilingual (Chinese/English) fan guide for a co-op game, I leaned on a Valve endpoint that more people should know about: the global achievement percentages API.

https://api.steampowered.com/ISteamUserStats/GetGlobalAchievementPercentagesForApp/v2/?gameid=<APPID>

It returns, for a given app id, the share of all players who have unlocked each achievement. No scraping, no private dashboard — one JSON call.

The shape

The response is small: an achievementpercentages.achievements[] array of { name, percent } where name is the internal API name (not the store display name). For the game I was documenting (app 1478500) it produced a clean funnel:

achievement (apiname)	% of players
Drawbridge	87.6
Map	64.7
Backpack	57.0
Chairlift	44.2
Train	37.8
Holster	36.2
Tunnel	30.2
Peak	28.8
Wall	20.2
Ending1	19.1
Shiny	9.4
Ending2	6.0

Sorted ascending, that is a retention curve. Nobody had to build telemetry; Valve already published it.

Three things that will bite you

The numbers move. These are live shares over a changing denominator. Re-reading the same endpoint ~2.5 weeks later, the rarest achievement had already gone 6.0% → 7.1%. If you display these, store and display the date you read them, or you'll publish a number that quietly goes stale.
name is the apiname, not the label. Ending2 is not what the store page calls it. You have to maintain a mapping, and the mapping is your inference — label it as such.
Rounding is a choice. The endpoint returns floats; how you round is a presentation decision, not data. Say so.

Why it made the site better

The interesting part isn't the API — it's what it lets a small site do honestly. Instead of "10 tips" filler, the guide can lead with a real, primary-source, independently verifiable dataset, and put its methodology and its data-drift caveats on a public /sources page. It also made i18n matter: the same numbers ship on two locale routes (/zh-CN and /en) with identical values mirrored per locale, so the Chinese and English pages can never disagree.

If you're building anything game-adjacent, this endpoint is worth an afternoon. It's public, it's structured, and it's a genuine story about where players actually stop playing.

I wrote it up against the game Big Walk on the Big Walk Guide's achievements page — an independent fan project (no affiliation with House House, Panic or Valve), with the collection date and the funnel arithmetic published alongside the figures.

Counting a phrase across the King James Bible — and why "fear not" is not 365 times

MakeInterview — Thu, 01 Oct 2026 10:59:03 +0000

You have probably seen the claim. It circulates in sermons, devotionals, and
wall art: "The Bible says 'fear not' 365 times — one for every day of the year."

I wanted to know if it was true. That turned into a small data-engineering
problem, and the answer is a useful example of how a plausible number survives
because nobody checks it.

The short answer

Counted against the King James Version with a stated, reproducible rule:

Rule	Verses
Exact phrase `fear not`	62
Exact phrase + common inflections (`fear not`, `feared not`, `fearing not`)	70
`fear` in any form	400 occurrences in 385 verses

Not 365. Not close. The popular figure has no documented source — it does not
appear in a concordance, and the "365" was likely chosen because a year has 365
days, not because anyone counted.

Why this is a counting problem, not a trivia problem

Three things make naive counting wrong, and they are the same three things that
make any text-analysis pipeline wrong:

1. Define the unit. A verse is the KJV's own versification. An
occurrence is a substring match. "400 occurrences in 385 verses" and "62
verses" are answering different questions, and both are correct. Most disputes
about counts are really disputes about the unit.

2. Inflection. English "fear not" is a fixed phrase, but the underlying
verb inflects: feared not, fearing not, fear thou not. A regex on the
exact string undercounts. And there is no clean place to stop — every added
variant is a judgment call you have to write down.

3. Translation. The KJV and the Chinese Union Version (和合本) do not agree,
because they are not literal mappings of one another. 和合本 uses four separate
不要 constructions. Counting one and reporting it as "the Bible" is a category
error.

The rule I used

Be explicit, and let a reader reproduce it:

Corpus: KJV (public domain), verse-indexed.
Normalize: uppercase, collapse whitespace, strip punctuation except apostrophes (so fear not and fear not. match, but fearn't is not invented by over-eager stripping).
Match on word boundaries, not substrings — otherwise fear matches fearful, God-fearing, and fearfulness, which inflates the count by roughly 15%.
Report verses for phrase claims, occurrences for word claims.
Publish the matched verse list, not just the total. A count you cannot audit is not a result.

The full rule and the matched verses are in the dataset (below), one row per
matched verse, so you can diff my work rather than trust it.

The dataset

CC-BY-4.0 — reuse it, including commercially, with attribution:

CSV: https://trustbible.org/data/fear-not-counts.csv
JSON: https://trustbible.org/data/fear-not-counts.json
Written-up methodology: https://trustbible.org/blog/how-many-times-does-the-bible-say-fear-not/

Columns are reference, book, chapter, verse, text, matched_phrase, rule — the
rule column is what makes it auditable, because it tells you why each row is
in the file.

What I took away

If you publish a number, publish the rule that produced it. A count with a
stated rule can be checked, corrected, and cited. A count without one is a
rumor with a decimal point.

If you find an error in mine, I would genuinely like to know — that is the
point of putting the method on the page next to the result.

I built the counting pipeline behind this while working on
TrustBible, a Bible Q&A tool that quotes the exact
verses it cites. The counts above are independent of the app; the dataset is
the deliverable.

What I learned building an AI voice mock-interview tool

MakeInterview — Thu, 01 Oct 2026 03:30:11 +0000

Job seekers in China practice interviews the same way most people do everywhere: by reading question lists, or by rehearsing silently in front of a mirror. Neither gives the one thing that transfers to the real room — being asked out loud, and having to answer in the moment.

I've been building MakeInterview, a voice mock-interview tool for Chinese-speaking candidates. Five engineering and product decisions turned out to matter more than the prompt engineering.

1. The interviewer has to follow up

A real interviewer does not wait for a perfectly composed 90-second answer. They dig in. The biggest realism gap in the early version was that the model waited, patiently, for a full turn and then moved on.

Modeling the interview as a turn loop, where the interviewer is allowed to follow up once or twice before moving to the next question, changed the transcript from "candidate monologues" into something that resembles an actual conversation.

2. Ground the questions in your resume and the JD

Generic questions test generic memory. The product only becomes useful when the question is about the project you actually listed. We parse the candidate's resume and the target job description, then require every generated question to anchor to a specific entity from them. If the parser cannot find something to anchor to, the interviewer asks a clarification instead of inventing a plausible-sounding project.

3. Show the transcript, not a vague score

Early feedback was a number out of 100. Nobody improves from a number. What moved the needle was showing the verbatim transcript — the exact words the candidate said — next to a model answer. Candidates are often surprised by their own filler words and hedging. The transcript makes that visible without an argument.

4. What the research actually says about interviews

The value of structured interviews is not folklore. Schmidt and Hunter's meta-analysis (1998), and its 2022 update by Sackett et al., place structured interviews among the highest-validity selection methods — well ahead of unstructured ones. That is the design constraint: keep the interviewer structured, not chatty.

5. Multiple personas, not one

A single friendly-interviewer persona produces one kind of practice. We run five — an HR screener, a direct manager, a technical expert, a department head, and an executive. Same candidate, different pressure, which is closer to how a real interview loop feels.

What I would tell another builder

If you are building a voice agent for a high-stakes conversation, the interruption and follow-up loop is the part I would spend the most time on. A patient model is easier to build and much less useful. The second most valuable thing was refusing to summarize the candidate's answer for them: the transcript, warts and all, is the feedback.

MakeInterview is at makeinterview.com if you want to try it. It is Chinese-first — the questions and the feedback are in Chinese.