HIIRD/Interview guides/Technical
The technical interview: knowing it is half. Saying it is the other half.
Technical interviews test two things at once: whether you know your field, and whether you can explain it to another human under pressure. Plenty of skilled people fail on the second half.
What technical interviews look like in different fields
"Technical interview" sounds like coding on a whiteboard. That is one version. Any job that needs specialized knowledge has its own:
- Knowledge questions. "Explain how you would..." or "What is the difference between..." Common in accounting, nursing, IT support, and the trades.
- Live problems. You work through a problem in front of the interviewer: a coding exercise, a spreadsheet, a case.
- Practical or skills tests. You do a piece of the actual job: a typing or data entry test, a hands-on task, a role-play with a "customer."
- Take-home assignments. A small project you complete on your own time and then walk through.
- Portfolio or project walkthroughs. You explain something you have built, written, or designed, and they dig into your choices.
Ask the recruiter which format to expect. It is a normal question, and the answer changes how you prepare.
Why employers test this way
Because it works. The US Office of Personnel Management notes that performance on job knowledge tests and on work samples "relates highly to performance on the job." Asking you to do or explain the real work is one of the most direct ways to predict whether you can do it.
What actually gets scored
Beyond correctness: how you organize an answer (frame the problem, walk the approach, land the solution), whether you use your field's terms precisely, whether you understand WHY and not just WHAT, and whether you acknowledge limits and tradeoffs. The word "best" with no context is a quiet red flag in every technical field. Best for what, under which constraints?
Think out loud and ask questions
In a live problem, silence is the enemy. The interviewer cannot score thinking they cannot hear. Say what you are checking and why, even when you are unsure. A wrong turn you explain and correct often scores better than a right answer that appears out of nowhere.
Start by asking one or two clarifying questions. Real problems come with missing information, and asking about it is part of the skill. "Is this for one location or all of them?" "Do we care more about speed or accuracy here?" Then restate the problem in one sentence before you start.
The honesty rule
When you hit the edge of your knowledge, say so, then show how you would find out. "I have not worked with that, but based on what I know about X, I would expect..." scores dramatically better than bluffing. Interviewers probe suspected bluffs, and a caught bluff can undo an otherwise strong interview.
Two worked examples
Accountant, asked: "Walk me through how you would find an error when the books do not reconcile"
"First I would size the difference, because the amount itself is a clue. A round number suggests a single missed entry. A difference divisible by nine often means two digits were swapped. Then I would work newest to oldest, since recent entries are the likely culprits, and check the handoffs first: bank feeds, imports, manual journals. What I would not do is start recounting everything from January, because unstructured checking burns hours and misses patterns. Last year we were off by $180. That is divisible by nine, so I searched for swapped digits and found a $1,530 invoice keyed as $1,350 in about twenty minutes."
Method first, reasons for the method, an honest note about what NOT to do, and a real case with numbers as proof. Even in a numbers profession, the interview answer is a story about thinking.
Junior data analyst, asked: "How would you check whether a dataset is ready to analyze?"
"I would start with the basics before touching any charts. Does the row count match what I expected? Are there duplicate IDs? How many values are missing in each column, and is that random or clustered? Then I would check ranges for things that cannot be true, like a negative quantity or an order dated next year. Last, I would compare one total against a source I trust, like monthly revenue from finance. In my capstone project, that last check showed our export was counting refunds twice, which would have inflated sales by about 4 percent."
Clear order, a reason behind each step, and a real catch as proof. Notice it never uses a tool name to sound impressive. The method is the answer.
How to prepare
- List every tool, skill, and term in the job posting. For each one, make sure you can explain what it is and when you would use it, in two sentences.
- Review the fundamentals of your field, not just advanced topics. A shaky answer on a basic concept hurts more than a gap on an edge case.
- Pick one project you know inside out and practice explaining it start to finish: the problem, your choices, what went wrong, and the result.
- Practice explaining a concept to a smart friend outside your field. If they cannot follow it, an interviewer will not either.
- Do a timed practice problem out loud, narrating as you go. It feels awkward the first time and normal by the third.
The mistakes that cost offers
- Jumping to the answer with no framing. Right but unorganized reads as lucky.
- Going silent while you think.
- Calling anything "best" without naming the tradeoff.
- Bluffing past a gap instead of naming it.
- Explaining to impress instead of to be understood. If a smart outsider could not follow you, it did not land.
Sources
- US Office of Personnel Management, Job Knowledge Tests.
- US Office of Personnel Management, Work Samples and Simulations.
Practice this interview out loud, tonight.
HIIRD is an AI interview coach for iPhone. It runs the interview, listens to your answers, coaches you live, and scores every response. Free to try on the App Store.
Get HIIRD.