DEV Community: MakeInterview

Why "It Depends" Is a Bad Opening Line in a Technical Interview

MakeInterview — Fri, 09 Oct 2026 15:11:43 +0000

"It depends" is technically correct and practically useless as an opening line. The interviewer already knows it depends. What they are waiting for is the sentence that shows how you decide.

Say the constraint first

Almost every design question hides one unstated constraint: read-heavy or write-heavy, one region or many, latency budget, team size, budget. Name the constraint you are assuming before you name your solution.

Compare:

"It depends. There are several options..." — the room waits.
"Assuming read-heavy and a few milliseconds of allowed staleness, I would start with a read replica and a short cache." — now we are discussing engineering.

The second version can be argued with, and arguing with it is exactly the point. A wrong assumption out loud gets corrected in two seconds. A vague answer gets marked as vague and never recovers.

Commit, then qualify

Give a primary answer, then at most two caveats. Candidates who open with a menu of alternatives lose the thread of their own answer, and the interviewer stops following it. Candidates who commit and then name the one condition that would change their mind sound like someone who has shipped before.

The caveat is the interesting part. "I would do X unless the write path is the bottleneck, in which case I would do Y" tells the interviewer you know where the bodies are buried. It also gives them an easy follow-up, which is what they were going to ask anyway.

Where the third beat goes

Structure works the same way outside system design. For behavioural questions, context, action, result beats a chronological retelling every time — most stories collapse because the result arrives last, after the listener has already stopped caring.

The skill is the same in both cases: land the point early, then add detail only if asked.

That is the loop worth practising out loud. Speaking an answer exposes filler and buried conclusions that look fine on paper. MakeInterview runs that drill as a scored mock — you talk, it marks where the structure broke.

Related reading on this blog: practicing answers out loud, and why follow-up questions derail otherwise good answers.

How to practice interview answers out loud (and why silent prep fails)

MakeInterview — Sun, 04 Oct 2026 12:17:43 +0000

I have sat through enough mock interviews to notice the same pattern: the candidate knows the answer, and it still comes out flat.

The gap is almost never knowledge. It is delivery. In your head an answer sounds complete. Out loud it has filler words, a rushed middle, and a conclusion that trails off. You only hear that when you actually say it to someone — or to something.

The part silent prep misses

Reading a question and mentally drafting an answer is recall practice. It trains retrieval, not performance. An interview tests performance under mild stress: someone is listening, the clock is running, and you cannot edit the sentence after you have said it.

So the useful loop is short:

Answer out loud, once, without notes.
Listen back for filler words and pace.
Redo just the weak section.

That is it. Ten minutes of that beats an hour of silent review.

I built MakeInterview around exactly this loop — it runs a spoken mock interview and gives feedback on how the answer sounds, not just what you meant. The point is not the tool; it is that you have to hear yourself before you can fix the delivery.

Vectorizing a logo vs. a photo: why the same tool gives you junk on one

MakeInterview — Sun, 04 Oct 2026 09:11:27 +0000

"Just vectorize it" hides a fork. A logo and a photo need opposite strategies, and using one tool for both is why half your exports come back as blobs.

Logos and icons want sharpening

A logo is flat regions with hard edges and flat color. The right pipeline finds the boundaries between color regions and fits closed paths to them. You want few nodes, exact corners, and solid fills. Trace with too much path detail and you get wobbly edges and thousands of nodes for a shape that should be a dozen control points.

What to check on the output:

Fill the shape with a new color — it should take, because it is a real region.
Count nodes. A clean 4-color logo should land in the low hundreds, not tens of thousands.
Zoom to 800% and look at a straight edge. It should stay straight, not ripple.

Photos want smoothing, not detail

A photograph has no hard regions. Chasing per-pixel detail produces a noisy mess of speckles that is larger than the original and looks worse when scaled up. Here you want aggressive merging of near-collinear points, a speckle filter, and a limited palette. The goal is a poster-like reduction that reads cleanly, not a node-per-pixel reproduction.

The test that separates them

Open the output in a text editor:

<svg ...>
  <path d="M12 4 L28 4 L28 20 Z" fill="#1a73e8"/>   real geometry, good for a logo
  <image href="data:image/png;base64,...."/>          wrapped bitmap, not a vector
</svg>

If you see <image>, the extension lied. If you see a handful of <path> elements, you have something you can scale, recolor, and cut.

Why the distinction changes your tooling

Cutting (CNC, plotter, Cricut): needs closed paths. A wrapped bitmap cannot be cut at all.
Theming (dark mode, brand recolor): needs fills, not pixels.
Web weight: a few KB of path data beats a 400 KB base64 blob, and it stays crisp at every DPI.

I benchmarked a converter on both classes of image and wrote up the measured differences — edge fidelity, node counts, file sizes — at pic2svg. The takeaway is boring but load-bearing: match the strategy to the image type, then measure what came out instead of trusting the file extension.

The Interview Answer You Can't Defend — and How to Find It Before the Interviewer Does

MakeInterview — Sun, 04 Oct 2026 05:32:28 +0000

Most people prepare for the interview they imagine. They rehearse an introduction, memorize a couple of project stories, and practice "tell me about a time when…" until the words feel smooth.

Then the interviewer reads the resume line by line and lands on the one sentence you never practiced defending.

I've seen this from both sides of the table. The pattern holds: the question that sinks an interview is almost never a hard technical question. It's a small factual probe about something you wrote down months ago and haven't thought about since.

It's worth understanding why interviewers do this, because the why tells you exactly what to prepare.

They aren't being hostile — they're verifying

Structured interviews are one of the better-performing selection tools we have. That finding goes back at least to Schmidt and Hunter's 1998 meta-analysis and was refined by Sackett and colleagues in 2022. The short version: asking every candidate the same job-relevant questions and scoring the answers against a defined rubric predicts job performance better than the unstructured "let's just chat" version.

A structured interview has a resume-verification component almost by design. The interviewer has a page of facts. Their job is to check whether those facts hold up and whether your stated contribution matches the story. So they probe — and they probe the parts a careful reader would notice.

That's the useful part: the targets are predictable, even if the exact questions aren't.

The three lines that get probed

Almost every resume drill lands on one of three things. Find them on your own resume before the interview and you can prepare for them.

1. The gap. A stretch with no dates attached, or a range that doesn't follow the previous one. The follow-up is calm but specific: "What were you doing between March and September?" This isn't automatically a problem — people take time off for a dozen legitimate reasons. The problem is a vague answer, or one that contradicts the timeline you gave earlier in the same conversation.

2. The short tenure. A role that lasted six months, then another that lasted four. The interviewer wants to know whether there's a pattern and whether you can describe it honestly. The follow-up sounds like: "That one was short — what happened?" "It just wasn't a fit" invites the same question again. Naming the specific mismatch — the mandate shifted, the role was re-scoped, the team was restructured — sounds like someone who understands their own career.

3. The number with no method. "Improved conversion by 40%." "Reduced latency by 60%." These are the easiest lines to write and the hardest to defend, because the immediate follow-up is: How was that measured? Over what window? Against what baseline? Did you measure it, or did someone hand you the number? A modest claim you can explain beats a bigger one you can't.

What a defensible answer looks like

A defensible answer has three parts, and none of them require you to sound impressive.

The plain fact, in one sentence. "I left in June and started the next role in September."

The reason, without spin. If it was a layoff, say layoff. If you took time off to care for family, say that. If you were looking, say you were looking. Interviewers have heard everything; what they're testing is whether you'll be straight about it.

The forward link, one sentence connecting that fact to the job in front of you. "That's part of why I'm targeting smaller teams where the mandate is clearer," or "I used that time to finish a certification, which is why I'm moving toward backend infrastructure."

The same structure works for a number: the metric, the method, your role. "The 40% was signups over a six-week A/B test; I ran the experiment, my manager set the target." That's stronger than a rounder number you can't account for.

Why you have to say it out loud

Here's the part reading notes can't fix.

When you read a prepared answer, you're doing recognition: "yep, that's roughly what I meant to say." When you say it out loud, you're doing recall, and recall is what the interview actually requires. The gap between the two is where trouble lives.

Speaking also exposes what reading hides: the hedge word you didn't know you used ("I sort of led"), the place you trail off, the sentence that looked fine on paper and comes out defensive. You only catch those by hearing them.

Which is why the highest-value practice isn't writing better answers. It's answering out loud, getting interrupted mid-answer with a follow-up, and reading the transcript afterward.

How I practice this

For the out-loud part I use MockLive. You upload a resume, pick one of five interviewer roles — HR screen, direct manager, technical expert, department director, executive final round — and answer voice questions. It interrogates the weak spots on your resume and returns a report that quotes your own words back at you, flags the sentence that didn't hold up, and lets you replay the audio. The first session is free, so it works as a low-stakes place to get asked the question you're actually afraid of.

Try it on yourself

Before your next interview:

Read your resume as a stranger would, and mark every gap longer than three months, every role under a year, and every number with no method behind it.
For each mark, write one plain sentence describing what happened.
Say it out loud, alone, twice. Notice where you stumble or start over-explaining.
Have someone interrupt with "why?" after each sentence. If you can answer the follow-up without getting defensive, it's ready.
If you can't, that's the line to work on before the interview — not the introduction.

The introduction is the part you've already rehearsed. The line you can't defend is the part that decides the interview.

If you want a place to practice getting asked out loud, try it at https://makeinterview.com.

Your 'vectorized' SVG may still be a bitmap — 4 checks, with measurements

MakeInterview — Sun, 04 Oct 2026 04:46:18 +0000

When you "vectorize" an image, the result is supposed to be paths — geometry you can scale, recolor, and cut. A surprising number of tools, including Inkscape's own Trace Bitmap, instead wrap the original bitmap in an <svg> tag, so the file is a picture inside a vector wrapper. It looks fine at 100% and falls apart everywhere else.

You can tell which one you got in about a minute. Here are four checks, then the numbers from a benchmark I ran.

Check 1 — count the `<image>` elements

Open the SVG in a text editor and search for <image.

A non-zero count means a raster picture is embedded, and the file is at least partly a bitmap in a vector wrapper. Zero is a good sign, but not the whole story (see check 3).

Check 2 — compare bytes with and without the bitmap

Strip every <image> element and compare the file sizes. The delta is exactly how many bytes of picture were hiding inside.

# bytes with the embedded bitmap removed
python3 - <<'EOF'
import re
s = open("out.svg").read()
print(len(s.encode()), "->", len(re.sub(r"<image\b.*?</image>|<image\b[^>]*/>", "", s).encode()))
EOF

If the file drops by 70% when you remove the image, the image was the artwork.

Check 3 — is the visible shape actually made of paths?

Path count is the giveaway. If the artwork you see has rich color but the <svg> contains 4 <path> elements, those paths are not drawing your picture — the embedded bitmap is.

Check 4 — render it huge

Rasterize the SVG at 20× and zoom in. Real vector paths hold a clean edge; an embedded bitmap goes soft and pixelated the moment you pass the source resolution.

What the measurement actually showed

I ran three tracers on three inputs on one Apple-silicon Mac, twice each on two dates (2026-09-28 and 2026-09-29). The harness recorded offline: true — not one call left the machine. Two inputs kept identical SHA-256 hashes across both runs and produced byte-identical Inkscape and potrace output, so the columns below are reproducible.

Input	Tool	Bytes	Bytes excl. bitmap	`<path>` elements	Distinct colours	Embedded `<image>`
apple-touch-icon.png (180×180)	Inkscape 1.4.4 Trace Bitmap	29,689	20,869	7	7	1
apple-touch-icon.png	potrace 1.16	1,322	1,322	1	1	0
apple-touch-icon.png	any2svg engine (VTracer 0.6.15)	1,027	1,027	3	3	0
og-image.png (1200×630)	Inkscape 1.4.4 Trace Bitmap	550,602	460,883	8	8	1
og-image.png	potrace 1.16	21,718	21,718	88	1	0
og-image.png	any2svg engine	32,583	32,583	236	93	0
synthetic-flat.png (800×600)	Inkscape 1.4.4 Trace Bitmap	6,759	1,605	4	4	1
synthetic-flat.png	potrace 1.16	771	771	1	1	0
synthetic-flat.png	any2svg engine	3,068	3,068	6	6	0

Three things fall out of this:

Inkscape's stock Trace Bitmap exported exactly one embedded <image> every time — all three inputs, both dates. The bare <image> count is not a perfect verdict on its own, but here it fired on every single run.
potrace is honest but 1-bit. It never embeds a bitmap, and it never produces more than one colour layer. Perfect for a stencil, useless for a logo.
Path count tracks "is this really a vector". The icon that came out as 3 paths and the photo-derived banner that came out as 236 paths are genuinely editable; the 7-path Inkscape file is a 20 KB bitmap with a thin vector coat of paint.

Why this bites harder than it looks

CNC, laser, and vinyl cutters consume the paths, not the pixels. A raster-in-a-wrapper produces a toolpath around the image bounds, not the shape you wanted.
Web use means shipping a 550 KB "SVG" that could have been 30 KB, then watching it blur on a retina display.
Editing is the loudest tell: try to recolor a single region of an embedded bitmap inside a vector editor. You can't, because there is no path there to select.

Getting a real one

If you'd rather generate than audit: potrace is the right tool for flat, high-contrast art. For photos, logos, and multi-colour artwork you want a colour tracer that emits genuine filled paths.

Full disclosure: I build one — pic2svg, the engine in the table above. It's a hosted tracer (image posted to the API, traced there), free to trace and preview, with a paid tier for downloads. But the point of this post is the checklist, not the pitch: run checks 1–4 on whatever tool you already use, and you'll know in a minute whether you're holding vectors or a picture in a costume.

The raw measurements and the exact commands are published at pic2svg.com/offline-vector-converter-benchmark if you want to reproduce or dispute them.

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.