You can be good at technical interviews and still do badly at this one. In recent times, most software engineers have applied for a job only to receive a link that takes them to a platform such as Micro1 or Karat for an initial AI technical screen.
That is the part people underestimate. An automated screen is not a harder version of a phone screen; it is a different measurement, and most of the preparation that carries you through a human interview quietly stops working. Rapport does nothing. Reading the room does nothing. The recovery move where you notice a flicker of doubt and add "well, depending on the write pattern" does nothing, because nothing flickered.
What is left is the text of what you said.
This is a practice routine for that. Not a list of questions to memorise, because memorising questions is the failure mode, but a way to rehearse that matches what the round actually measures.
First, the one thing that changes everything
Your answers are scored as a transcript.
Every piece of advice below follows from that single fact. If you internalise nothing else, internalise that a human who likes you fills in your gaps and an automated score does not. A human hears half an idea, recognises the shape of the rest, and moves on. Automated scoring reads what is there.
So the bar moves from "did you know it" to "did you say it". Those feel like the same thing from the inside. They are not.
If you want the full breakdown of what happens minute by minute, we wrote that up separately in what actually happens in an AI technical screen. This post assumes you know the format and want to get better at it.
Practise out loud. Yes, really out loud
This is the whole routine in one line, and it is the step everyone skips.
Reading a question and thinking "yeah, I know that" is not practice. It is recognition, and recognition is a much lower bar than production. The gap between knowing something and saying it cleanly, in order, in about ninety seconds, under a timer, is enormous. It is also the entire thing being measured.
Say your answers to an empty room. Record them on your phone and play them back once, which is unpleasant and worth more than an hour of reading. You will hear three things immediately:
- You start sentences you do not finish.
- You say "basically" and "kind of" before every technical claim.
- The strongest part of your answer arrived at the very end, after the listener had already scored the beginning.
None of those are knowledge problems. They are all production problems, and they only fix with reps.
Say the mechanism, do not imply it
Experienced engineers imply mechanisms constantly, because with another engineer it is faster and implying it is a status signal. In this round it reads as a gap.
Compare:
Yeah, you would not want to do that synchronously, it would block.
That call is synchronous, so it blocks the event loop. Node handles requests on a single thread, so while that runs, every other request on that process is waiting.
The first is what you would say to a colleague. The second is what gets credit. It feels like over-explaining. It is not over-explaining, it is the answer.
A useful test while rehearsing: after each sentence, ask whether a reader with no context could tell you understood the cause, or only that you knew the conclusion. Conclusions are cheap. Causes are the thing.
Prepare four projects, not twenty answers
Most people prepare topics. Prepare projects instead.
Pick four things you genuinely worked on. For each one, be able to state three things without hesitating:
- The constraint. What actually forced the decision. Not "we chose Postgres because it is reliable", but what property you could not do without.
- The alternative you rejected. And why it lost. An engineer who cannot name the road not taken usually did not make a decision, they inherited one.
- One number. Request volume, dataset size, latency before and after, team size. One real number does more for your credibility than a paragraph of adjectives.
Those three things answer the overwhelming majority of follow-ups, because follow-ups are mostly just "why" pointed at whatever you said last. If you have the constraint, the alternative and the number ready, you have somewhere to go every time.
Drill the why-chain
Here is the drill that changes scores fastest.
Take one of your four projects. Say your answer out loud. Then ask yourself why, and answer. Then ask why again. Then a third time.
Almost everyone hits a wall on the third why. That wall is exactly where an automated follow-up will find you, and finding it in your kitchen is considerably better than finding it in the round. You do not need to eliminate the wall, you need to know where it is, so you can say "I do not know, here is how I would find out" deliberately instead of discovering it live.
Do this on four projects and you have covered most of what a thirty minute screen can reach.
Structure every answer the same way
Under pressure, structure is what stops you rambling. Use the same shape every time:
- The answer, first. One sentence. Not a preamble, not a restatement of the question.
- The mechanism. Why that is the answer, stated causally.
- The trade-off or the limit. When it stops being true, or what it costs.
That third part is the one that separates candidates, and it is the one people leave out because it feels like undermining yourself. It is the opposite. Naming the limit of your own answer is the clearest available signal that you have actually used the thing rather than read about it.
Here is the same question with and without it.
Q: How would you speed up a slow endpoint?
Without: I would add caching. Probably Redis in front of the database, with a sensible TTL, and that usually takes most of the load off.
With: First I would find out where the time goes, because caching a slow query hides it rather than fixing it. If it is one N+1 query then an index or a join is the fix and caching is premature. If it is genuinely expensive and read-heavy, then a cache in front, and the real question becomes invalidation: a TTL is fine for data that can be stale for a minute, and not fine for anything a user just edited, because they will refresh and see their own write missing.
Same knowledge. The second one names a constraint, rejects an alternative, and admits a limit. It also cannot be produced by memorising an answer, which is precisely why it scores.
A realistic week
If you have a screen coming up and limited time:
- Day 1. Pick your four projects. Write the constraint, the rejected alternative and the number for each. Twenty minutes.
- Days 2 to 4. One project per day. Say it out loud, run the three-why drill, record one answer and listen back once.
- Day 5. Rehearse the answer shape on unfamiliar questions, so structure survives surprise.
- Day 6. Rest. Cramming the day before produces stiff, scripted answers, which collapse on the first follow-up.
That is roughly two hours total, distributed. Distribution matters more than volume here, because you are building a speaking habit rather than loading facts.
What not to bother with
- Memorising answers. They survive the first question and fall apart on the second, which is the one that counts.
- Rehearsing your confidence. Confidence with nothing underneath is the single easiest thing for a follow-up to expose.
- Breadth. A screen samples a few areas. Being genuinely deep in the four things you actually work with beats being shallow across twelve, every time.
The short version
Practise out loud, say the mechanism instead of implying it, know the constraint and the rejected alternative and one number for four real projects, and find your third-why wall before the round does.
None of that is about being smarter. It is about making what you already know legible to something that will not meet you halfway.
I build PracticeDepth, an AI interviewer that asks senior-level questions across sixteen topics, then drills into whatever you just said until it finds your ceiling, and tells you where you actually stand. A practice run is free and takes about twenty minutes. It is a lot less comfortable than reading a list, which is the entire point.
Top comments (0)