Contents
In brief
Generic interview question lists are useful only up to a point: they optimise for coverage, while a real vacancy reveals what a particular team is likely to assess. A Dev.to article shows how to turn that text into a small, local practice pack with Node.js.
The dependency-free script reads a job description and produces a JSON file with recurring terms, stack-specific questions, behavioural prompts, risk areas, and a seven-day rehearsal plan. It does not need an API key or a model call; the suggested role for AI comes later, as a sparring partner for real experience rather than its substitute.
What happened
The proposed command-line tool accepts a plain-text job description. It normalises the words, drops common English stop words, counts the remaining terms, and checks the text against a deliberately small mapping of technologies such as React, TypeScript, GraphQL, accessibility, and testing.
For every matching technology, the script adds questions that demand an explanation or an implementation decision. If the description mentions collaboration, mentoring, ownership, or reliability, it also adds behavioural questions. When a listed skill has no specific mapping, the program falls back to general prompts about production bugs, trade-offs, and explaining a technical decision to a non-engineer.
The output is intentionally transparent. A repeated word such as “reliability” becomes a visible reminder to prepare one concrete incident or project story, rather than a mysterious score calculated by a service.
Why it matters
The same “Software Engineer” title can mean very different work. A frontend platform role may centre on component APIs and accessibility; a payments backend role may probe failure modes and operational judgement. A broad checklist can leave a candidate practising the wrong material for hours.
Using the vacancy as an input does not predict an interviewer’s questions. It does, however, turn public signals into a prioritised rehearsal plan. Repeated technologies, business outcomes, and verbs in the responsibilities section are often more useful than a long, unranked list of interview advice.
The local-first design is also an important constraint. The first pass exposes the words as written, without a model smoothing them into generic advice. That makes it easier to challenge the result: is “checkout” really central to the role, and can you describe a real decision involving it?
In practice
- Save the responsibilities and requirements from a vacancy in a text file. Remove salary, benefits, and boilerplate unless they contain role-specific information.
- Run the script locally and inspect the returned keywords before treating them as priorities. A single accidental repetition should not outweigh the actual responsibilities.
- For each risk area, prepare a short, true story: context, constraint, decision, and result. Technical answers work better when they include a concrete trade-off.
- Rehearse answers aloud in roughly 60–120 seconds. Start with a structured outline, then repeat conversationally so the answer does not sound memorised.
- Add a tiny build exercise for the most important skill. For example, model an API result as a TypeScript discriminated union, or make a custom control keyboard-accessible.
After that deterministic pass, an AI tool can be useful for follow-up questions, tightening a rough STAR outline, or running a timed mock interview. It should not invent accomplishments: a fabricated story usually lacks constraints, metrics, and the human details that make an answer credible.
Takeaway
The script is not an applicant-tracking system and does not need to become one. Its value is narrower: convert a specific vacancy into a small set of prompts that can be checked, revised, and practised repeatedly.
For developer roles, that can shift preparation from “read another hundred questions” to “show evidence that I can do the work this team is describing.” The simple keyword pass is a starting point, not an authority; the candidate still has to choose relevant examples and understand their own decisions.