The technical phone screen

Same project as R1, completely different answer. The recruiter version was four beats and no jargon. This version has architecture, a number, and a problem you solved that was genuinely hard.

Shape it as what it does → how it is put together → the hardest part → what it cost or saved, and stop at ninety seconds so they can steer.

Roughly half of phone screens include a small problem in CoderPad, CodeSandbox or a plain shared doc. It is deliberately not hard — a string or array transform, a debounce, a promise sequencing task, a small React component. It is the "can this person type" round.

Two rules. Clarify the input shape before you write anything. And write the obvious version first — nobody has ever failed this for being O(n) instead of O(log n), and plenty have failed it by disappearing into a clever solution.

// group an array of objects by a key
// flatten a nested array without .flat()
// debounce(fn, ms)
// retry(fn, times) with async/await
// run promises with a concurrency limit of 2
// a <SearchInput /> that debounces and cancels the stale request

That last one is the one to have ready cold. It is the phone-screen favourite for anyone with React on their resume, and it has an obviously wrong answer — debouncing without cancelling the in-flight request, so a slow early response overwrites a fast late one.

Narrate at three moments, not continuously:

• Before you type. "I will build a map from key to array, then one pass to fill it — O(n), and it handles the empty case by returning an empty object."
• When you make a choice. "Using a Map rather than an object here so non-string keys survive."
• When you are stuck. Say what you tried and what you are considering. "The recursive version blows up on cycles — I am going to track visited nodes in a Set." A stuck candidate who is thinking out loud is a hire; a stuck candidate who goes quiet for ninety seconds is not.

Then shut up and type. Continuous commentary is as bad as silence.

This round rarely goes deep — it picks two or three from a small set and moves on. The whole set is in R3; the ones that show up at this stage specifically are:

• Event loop ordering. A setTimeout(0) and a resolved promise in the same tick — which logs first, and why microtasks drain before the next macrotask.
• Closures. The var-in-a-loop classic, and what let changes about it.
• this in an arrow function versus a regular function, in a class method passed as a callback.
• Shallow versus deep copy, and what spread actually does to a nested object.
• One TypeScript question if TS is on the job description — usually interface versus type, or what unknown buys you over any. That is R3·TS.

Answer in three sentences and stop. Long answers in a phone screen eat the coding time and the interviewer is watching the clock.

In smaller companies the first technical conversation is with the person you would report to, and the questions change shape completely. They will ask why this role, what you want to own, how you work with a team, and what you are looking for in your next two years — with one or two technical probes to confirm the resume.

Three things to get across, all of them things a manager buys:

• Ownership, not tasks. "I own release and reliability for four applications" is the sentence. Feature lists are not.
• A reason to want this job specifically. The client-studio-to-product story from R1 works here and lands harder, because this person lives the difference.
• A question about scope. "What would you want me to own in the first six months?" It is the question a senior asks and a mid-level does not.

Different questions from the ones you asked the recruiter — this person can answer things nobody else in the loop can, and their answers tell you whether the job is actually good.

• What does the codebase look like today — where is the pain? The honest answer tells you what your first year is. An engineer who says "there is no pain" is either new or not listening.
• How does something get to production here? Branch, review, CI, who presses deploy. This is the single most predictive question about your day-to-day.
• What is on call like? Ask before the offer, not after.
• What does the rest of the loop cover? They will usually tell you exactly what to prepare for, and that is a free advantage.

• Wired headphones and a tested mic. Laptop speakers plus a room echo makes forty-five minutes of you exhausting to listen to.
• The editor link opened five minutes early. CoderPad and CodeSandbox both take a minute to load and both can be blocked on a work network.
• A second network ready. Phone hotspot on standby, because it will be the day your wifi drops.
• A closed room and a silenced phone. If you must take it from the office, book a room — taking a technical call from a corridor is audible and it reads as unserious.
• Your resume open on a second screen, plus the four numbers you might be asked to defend. You will be asked about something on page two.