Software Engineer Interview Prep: A Starter Plan

Interview prep is the kind of task that expands to fill all available time. There is always one more LeetCode problem, one more system-design video, one more rejection email. A plan helps. This post is one — opinionated about what to skip, practical about what to keep.

If your resume is what gets you the call, this is what gets you the offer. (For the resume side, see Resume Tips for Software Engineers.)

The realistic loop

A typical engineering loop, for early to mid-career candidates, looks roughly like:

1. Recruiter screen (30 minutes). Background, motivation, salary, logistics. Low stakes if you’re prepared.
2. Technical phone screen (45–60 minutes). Usually one or two coding problems on a shared editor. Sometimes a short conversation about your background.
3. On-site / virtual loop (3–6 hours). Spread across one or two days:
   • 1–2 coding rounds
   • 1 system-design round (less common for new grads; common from mid-level up)
   • 1 behavioral round
   • Sometimes a domain round (debugging, language-specific, take-home review)
4. Team match / hiring committee. Sometimes a final conversation with a hiring manager. Often a black box you have no control over.

The exact mix varies. Backend-heavy companies lean into system design earlier. Frontend roles often include a take-home build. Smaller companies replace one round with a pair-programming session on a real codebase.

The key insight: each round tests something different. Prep accordingly. Grinding only LeetCode for an on-site that includes design and behavioral is a way to underperform on two of four rounds.

Where to study

A short, opinionated list of what’s worth your time.

• Coding rounds. LeetCode for problems; NeetCode for a curated roadmap. A focused 150-problem list beats unfiltered grinding.
• System design. “Designing Data-Intensive Applications” (Kleppmann) for the why; the System Design Primer on GitHub for the what; Hello Interview and ByteByteGo for worked examples.
• Behavioral. Your own past projects, replayed honestly. The template comes from one short article (see STAR below) — the substance comes from your work.
• Company-specific. Glassdoor and the Blind app for recent question patterns. Read with skepticism — bias toward people who didn’t get offers.

What to skip: comprehensive computer science textbooks if you already have a CS background, “fundamentals” YouTube series longer than two hours, and any course that promises to “guarantee FAANG offers.”

A six-week plan that works

For a candidate with a full-time job, six weeks is realistic. Less is possible if you’re already strong on one axis.

• Week 1. Diagnose. Do five LeetCode mediums under time pressure. Watch two system-design videos. Write out your three best projects. Notice where the gaps are.
• Weeks 2–3. Coding focus. Work through a curated pattern list — arrays, hashmaps, two pointers, sliding window, BFS/DFS, dynamic programming. Two to three problems daily, mixed.
• Week 4. System design focus. Pick three classic problems (URL shortener, news feed, chat) and design each end to end on paper. Read one or two reference designs for each.
• Week 5. Behavioral and mock interviews. Schedule two to three mocks. Write STAR stories for the six most common prompts (see below).
• Week 6. Polish. Mixed coding and behavioral. Cool down the day before each real interview.

Adjust to your situation. The structure matters more than the exact week boundaries — sustained, deliberate practice beats a chaotic sprint at the end.

Deliberate practice, not grinding

Grinding is doing 400 LeetCode problems. Deliberate practice is doing 80, slowly, and getting better at them.

A pattern that works for coding problems:

1. Read the problem carefully. Don’t start typing yet. Identify the inputs, outputs, and edge cases.
2. Brute force out loud. State the simplest correct approach and its time complexity. Don’t be embarrassed by an O(n²) start.
3. Optimise. What’s the bottleneck? What data structure makes it cheaper? Hash map? Sorted order? Two pointers?
4. Code it. Aim for readable first, fast second.
5. Test it. Walk through your code on a small example. Then an edge case. Then the empty case.
6. Reflect. What pattern did this fit? What would you do differently if you saw it again?

That last step is the one most people skip. A spaced-repetition note (“two-pointer + hashmap” → “this problem and three like it”) is worth more than five new problems.

If a problem takes more than 40 minutes, look at the answer, understand it deeply, and re-attempt the problem two days later from scratch. Staring at the same problem for two hours teaches you very little.

Mock interviews are non-negotiable

The single highest-leverage prep activity. Reasons:

• Coding under observation is a different skill from coding alone.
• Talking through your thinking out loud is a muscle that needs reps.
• A neutral interviewer notices habits you’re blind to.

Where to find them:

• A friend who interviews engineers. Best option if you have one.
• interviewing.io, Pramp, Exponent. Paid or free peer matching.
• Your current colleagues. Not always advisable for confidentiality reasons, but a trusted peer is gold.

Aim for at least three before your first real interview. Record yourself if your platform allows. Watching it back is uncomfortable and very effective.

Talking while you code

The interviewer is not testing whether you can solve the problem. They’re testing whether they want to work with you on hard problems. Almost the entire signal comes from how you talk through it.

A simple structure:

1. Restate the problem. “So I have an array of integers, I need to return the indices of two that sum to a target. Are inputs guaranteed unique? Can there be no solution?”
2. Walk through a small example. Out loud. With paper or comments.
3. State your approach before coding. “I’ll use a hashmap from value to index. As I iterate, I check whether target - current is in the map.”
4. Narrate as you code. Not every line — but every decision. “I’ll initialise the map empty. I’ll iterate with enumerate so I have indices.”
5. Test out loud. “On [2, 7, 11, 15] with target 9, the map after index 0 is {2: 0}. At index 1, 9 - 7 = 2 is in the map. Return [0, 1]. Correct.”

When you get stuck, say what you’re stuck on. Silence reads as panic; “I’m not sure whether to sort here or use a hashmap — let me think about which scales better” reads as engineering judgement.

When you make a mistake, just fix it. Don’t apologise three times. “Off by one — let me adjust” is the whole apology you need.

System design: a tiny framework

Each system-design round is a 45–60 minute conversation. A loose framework keeps you from rambling.

1. Clarify scope. Functional requirements (what does it do?), non-functional (scale, latency, consistency).
2. Estimate. Back-of-the-envelope numbers. QPS, storage, bandwidth.
3. High-level design. Sketch the boxes: client, API, service, database, cache, queue. Talk through the request flow.
4. Deep dives. Pick two or three components and go deeper. Schema. Sharding. Failure modes.
5. Tradeoffs. Where would you pick consistency over availability? Where SQL over NoSQL? Why?

The interviewer’s job is to push on tradeoffs. Yours is to have honest answers. “I’d use Postgres here because the relations are clean and the scale fits; once we’re past a million users we might shard by user ID” is much better than name-dropping seven AWS services.

You’re not expected to know every component cold. You are expected to reason about choices.

The behavioral round and STAR

Behavioral interviews aren’t a soft round — they often decide ties. Companies use them to test ownership, collaboration, and judgement.

Use the STAR template for every story:

• S — Situation. Context. What was going on? (15 seconds.)
• T — Task. What was your specific responsibility? (15 seconds.)
• A — Action. What did you do? Not the team. You. The longest section. (90 seconds.)
• R — Result. What happened? Numbers where possible. What did you learn? (30 seconds.)

Prepare six stories — one each for:

1. A project you’re proud of
2. A time you disagreed with a teammate
3. A failure or mistake
4. A time you took initiative beyond your role
5. A time you had to deliver under pressure
6. A time you had to make a tradeoff between speed and quality

Most behavioral prompts can be answered from this set with minor reframing. The trick is to prepare the stories, not the answers — that way you can adapt to whatever prompt comes up without sounding rehearsed.

A common failure mode: candidates describe the team’s accomplishments in the first person plural. “We shipped it.” The interviewer doesn’t learn what you did. Use “I” deliberately.

The recruiter screen

Don’t underprepare for this. It’s filtering for fit and salary alignment.

• Have a 60-second answer for “tell me about yourself” — recent role, what you work on, what you’re looking for.
• Know your target salary range. Underselling here haunts the whole loop.
• Have one specific question about the company. (Not “what’s the culture like?” Something concrete.)

Recruiters are your advocates inside the company once they like you. Treat them well; they remember.

On the day

Practical notes for the actual interview.

• Sleep. No amount of last-minute cramming beats a rested brain. Stop studying the night before.
• Test the tech. Camera, mic, the coding platform’s editor, your IDE if you’ll share it.
• Have water and paper. Both are unreasonably helpful.
• Take a beat before answering. “Let me think for a second” is a complete sentence.
• Don’t post-mortem mid-loop. Between rounds, reset. Replaying the last round’s mistakes wrecks the next one.

After: the offer or the rejection

If you get an offer, negotiate. Always. The worst case is “no” and a hire who didn’t ask is a hire who left money on the table. A single follow-up email asking for 10–15% more is normal.

If you get a rejection, ask the recruiter for any feedback. Some companies share it; most don’t. Either way, write your own post-mortem within 48 hours while it’s fresh:

• Which rounds went well?
• Which didn’t?
• What was the specific moment in each round where you struggled?
• What would you study differently next time?

That document becomes the prep plan for your next loop. Rejections compound into expertise only if you treat them as data.

Common pitfalls

• Studying only one axis. Coding-only prep underperforms on design and behavioral.
• Grinding without reflecting. 200 problems with no retention is worse than 60 with deep retention.
• Skipping mocks. Reading is not practice.
• Memorising STAR scripts. Stiff and obvious to interviewers.
• Taking rejections as signal about your worth. They’re signal about a single conversation with a small slice of one company on one day.

Recap

You now know:

• The loop has distinct rounds — prep for each, not just coding
• Deliberate practice (slow, reflective) beats grinding
• Mocks are the single highest-leverage activity
• Talking through problems is a real skill — narrate decisions, not lines
• STAR structures behavioral answers; prepare stories, not answers
• After every loop, post-mortem honestly

Next steps

Pair this with Resume Tips for Software Engineers for the upstream side of the funnel, and the technical posts you’ll touch in coding rounds: pytest basics, Mocks, Stubs, and Fakes, VS Code shortcuts.

Questions or feedback? Email codeloomdevv@gmail.com.