Developer Mock Interview Guide — Practicing CS Fundamentals to Follow-Up Questions, One Axis at a Time

Four: CS fundamentals, project deep-dives, behavioral questions, and the deep technical round. CS fundamentals means knowledge checks on OS, networking, data structures, and databases; the project deep-dive probes the design decisions and troubleshooting behind what's on your resume; behavioral questions cover collaboration, conflict, and failure; and the deep technical round is the live coding, design discussion, or code review that follows a passed coding test.

You split them because each fails differently. CS fails on knowledge gaps, deep-dives fail on missing logic (the 'why'), behavioral answers fail on rambling without structure, and technical rounds fail when you can't think out loud. Different failure modes need different fixes — and if you practice everything blended together, you can't even see which one is broken.

The weighting depends on where you're applying. For juniors, CS fundamentals and project deep-dives usually carry the most weight; for experienced candidates, it shifts toward design judgment and collaboration stories. Read the job posting and any interview reviews for the company first, and decide where your hours go.

Stop reading with your eyes and answer out loud using a three-sentence frame: definition, comparison, application. For an index: 'An index is a data structure that speeds up reads (definition) — in exchange for write performance and storage (comparison/trade-off) — so in this project I only added them to heavily-queried columns (application).' Once that frame is automatic, any CS question has a skeleton.

Wherever you stall mid-explanation is your real gap. You thought you knew processes versus threads, but 'so why does context switching cost differ' stops you cold — that's the topic to restudy. Preparing one analogy per concept, as if explaining to a non-developer, tests your understanding and trains your delivery at the same time.

The thing to avoid is keyword recitation. 'TCP is connection-oriented, reliable, uses a 3-way handshake…' collapses under a single follow-up ('so when would you use UDP?'). Fewer topics you can explain down to the 'why it was designed that way' level beat a long list you can only name.

The entire preparation is building a three-step Q&A for every sentence on your resume: why that technology, what the alternatives were, and what the result was. If you wrote 'cached with Redis,' the set is: why Redis (versus a local cache or Memcached), what you cached and how you invalidated it, and what the response time went from and to. If you don't have numbers, measure now and fill them in.

'I didn't know better at the time' can be a good answer. If the honest reason for a technology choice was 'it had the most tutorials,' admit it and add 'here's the criteria I'd use to choose today' — that turns it into evidence you learn. It's far safer than inventing a justification after the fact, and no interviewer expects perfect decision-making from a junior.

Also practice drawing your architecture with words alone. No whiteboard — just walk the data flow out loud: 'a request comes in from the client, hits the gateway, then this service…'. Add one story each for a collaboration conflict, an incident or troubleshooting session, and a decision you regret, all in STAR form, and you've covered most of what a deep-dive can throw at you.

The most reliable method is attaching two expected follow-ups to every answer you've prepared, and practicing them as chains. 'I added an index to speed up reads' invites 'how did you order the composite index' and 'what do you check when it's still slow with the index on.' Digging just two levels deep — answer, follow-up, follow-up to the follow-up — removes most of the panic from the real thing.

When a follow-up lands outside what you know, the formula is: say what you know, show your reasoning, admit the rest. 'I don't know the exact internals, but if it's B-tree-based I'd expect this behavior — I'd want to verify that.' What the interviewer is measuring with follow-ups is where your knowledge ends and how you think past that point. Bluffing through one level just means collapsing harder at the next.

Follow-ups are hard to reproduce alone, so set an explicit rule with whoever runs your mock interview: at least two follow-ups per answer. Whether it's a study partner or an AI interview tool, keeping the follow-ups coming is the whole point of practicing this axis.

Solo practice costs nothing and is available instantly, which makes it right for drilling basics. Record your answers or film yourself to count filler words and check answer length, and explain CS concepts out loud rubber-duck style. The limits are just as clear: no follow-up questions, and no nerves.

The biggest gain from a study group is playing the interviewer. Hunting for holes in someone else's answer and inventing follow-ups builds the interviewer's eye, and that flows straight back into how you design your own answers. The tension of speaking in front of real people, and their improvised questions, only exist there. The trade-offs: scheduling, and feedback quality that depends on your group.

AI mock interviews are strongest at repetition — any hour, the same question as many times as you need. That fits drilling the same deep-dive question three to five times until the answer is automatic, plus consistent feedback on form (leading with the point, rambling). A tool like preterview, which runs a back-and-forth Q&A and turns it into a report, suits project deep-dive rehearsal, and it includes one free interview at signup to see if it fits. Whatever the tool, treat AI's technical judgment as a reference — verify technical facts against official docs.

Week one (D-14 to D-8) is for gathering material. Pull 30-40 likely questions across the four axes from the job posting and your resume, and draft answers per axis. This week's output is the three-step Q&A for your deep-dives (why, alternatives, result) and STAR drafts for behavioral questions. You're not rehearsing aloud yet — you're stocking things to say.

Week two (D-7 to D-3) is for saying it out loud. Take one axis per day and answer the same questions three times each, and schedule two or three mock interviews in this window — study group or AI, the format matters less than what follows: after every session, write a review note of the questions that stalled you, the answers that rambled, and the concepts you didn't know. A mock interview without a review note only adds to the count.

The last two days (D-2 to D-1) are for doing nothing new. Touching new questions or concepts now only feeds anxiety. Pick the five weakest answers from your review notes and polish those, re-read the company's product and engineering blog, and prepare three questions to ask them. The night before, condition beats practice.