How to use an interview question bank

Most engineers preparing for interviews have access to more questions than they could ever answer. Lists, banks, and repositories run into the hundreds. Yet plenty of people work through a large bank, recognise most of the prompts, and still freeze when an interviewer rewords one, adds a constraint, or asks them to defend a choice.

The problem usually isn't a shortage of questions. It's using questions as content to read rather than as tests to take. Research on retrieval practice backs this up: in a 2006 study, Roediger and Karpicke found that students who practised recalling a passage remembered more of it a week later than students who spent the same time re-reading it. For interview prep, the lesson is direct. A question bank works best as a testing system, not a reading list.

This guide covers how to turn a question bank into that system: how to sort questions so practice isn't random, how to pick the right difficulty, how to practise follow-ups, and how to keep a log that tells you what to practise next.

Why more questions isn't better preparation

Recognising a question is not the same as being able to answer it. "I've seen this before" feels like progress, but interviewers aren't checking whether you've met a prompt. They're checking whether you can reason through it out loud, under time pressure, while they push on your choices.

That gap shows up in a few familiar ways:

• You remember the shape of a solution but can't rebuild it from scratch.
• You know a canonical architecture but can't say why it suits this problem.
• Your behavioural stories sound fine until the first follow-up question.
• You've never practised with interruptions, ambiguity, or a clock running.

Reasoning out loud is part of the skill, not polish on top of it. An interviewer can't credit thinking they can't hear, which is why thinking aloud in a coding interview is worth practising on its own.

What makes a question bank useful

A useful bank does more than list prompts. It lets you filter, sequence, revisit, and rehearse them. Before you rely on one, check whether it helps you answer these questions:

• Which questions match the role I'm targeting?
• Which interview round does this question belong to?
• What is the interviewer trying to learn from it?
• What would a strong answer need to show?
• What follow-ups would expose a shallow answer?
• Have I got better at this kind of question since last time?

If it can't help with those, it's a catalogue. That's still useful for coverage, but you'll need to add the structure yourself.

Sort questions so practice isn't random

A taxonomy is just a way of tagging each question so you can see what you're practising and why. For software engineering interviews, five tags cover most of what matters:

A tagged entry might read: live coding, hash maps, core, edge cases, high relevance for a backend role. That tells you far more than a tick next to "done".

Coverage first, then depth

Coverage means you've met the range of topics a loop might include. Depth means you can handle unfamiliar versions of them. Both matter, but coverage is easier to count, so it tends to win.

A simple order works well:

1. Build coverage to see the landscape and find the gaps.
2. Build depth on the gaps most likely to come up for your role.
3. Test transfer by changing the prompt, a constraint, or how the interviewer behaves.

It helps to think in question families rather than single questions. For coding, families include two pointers and sliding windows, tree traversal, graph search, dynamic programming, intervals, and hash-map lookups. For system design, they're broader: read-heavy systems, write-heavy systems, event-driven workflows, multi-tenant APIs, data pipelines, rate-limited services, and systems where consistency really matters, like payments or inventory.

Someone who knows 25 families well is usually better prepared than someone who has clicked through 100 questions once. The live coding and system design round pages describe what each round tends to probe, which is a good way to choose families.

Pick the right difficulty

Questions that are too easy build false confidence. Questions far beyond your level produce struggle you can't learn much from. The useful zone is hard enough to show a gap and narrow enough that you can tell what the gap is.

A rough split to start from:

• About 60% core questions: what someone at your target level should handle reliably.
• About 30% stretch questions: harder variations and neighbouring topics.
• About 10% beyond your level: more ambiguity, unusual constraints, or unfamiliar domains.

These are starting points, not rules. If core questions keep tripping you up, shift time there. If they feel routine, move more into stretch. Hardmode runs each AI-led round at Easy, Medium, or Hard, so you can step the pressure up as you go rather than jumping straight to the toughest setting.

Practise the follow-ups, not just the opening prompt

A polished first answer is the easy part. Interviewers use follow-ups to find out whether it holds up:

• "What happens if the input no longer fits in memory?"
• "How would you make this safe under concurrent writes?"
• "Why that data model and not the alternative?"
• "What metric would tell you this design is struggling?"
• "What would you change if this had to ship in two weeks?"
• "What did you personally own on that project?"

For each question you practise, write down two or three likely follow-ups and answer those too. This matters most in a technical deep-dive, where one project from your CV can lead to questions on system knowledge, debugging, trade-offs, and how you worked with others.

A feedback loop that turns practice into progress

A feedback loop is the cycle of attempting, reviewing, adjusting, and trying again. It's what makes an hour of practice count. Here's one way to run it:

1. Read the role. Go through the job posting and note the stack, the scale, the seniority signals, the domain, and how much collaboration it mentions. The free interview plan tool turns a posting into the rounds likely in the loop and what each one probes, inferred from the posting.
2. Map the skills. Turn those notes into six to ten practice areas, such as API design, SQL, caching, incident response, coding patterns, or stakeholder communication.
3. Take a first pass. Try one or two questions per area without looking at solutions. Note the time, how confident you felt, and where you got stuck.
4. Rank the gaps. Put first the gaps that are both likely to come up and costly if they do. For a backend role, system design fundamentals usually matter more than an obscure puzzle pattern.
5. Practise in focused blocks. Work one family at a time: attempt a question, explain it aloud, review it, and write down the specific thing to change.
6. Come back with a variation. Two or three days later, solve a changed version without notes. Change the constraints, the scale, or the requirements.
7. Rehearse the real round. Move from single prompts to timed, conversational practice with clarifying questions and follow-ups.
8. Review weekly. Look for themes: what keeps coming up, how your answers are structured, how long it takes to reach a workable approach. Use that to choose next week's questions.

Keep a practice log

A practice log is a short record of what happened in each attempt and what you'll try next time. Without one, it's easy to repeat the same habit for weeks while feeling like you're getting more reps.

Keep each entry specific:

"Need more practice" isn't an entry you can act on. "I start coding before I've confirmed the requirements" is.

Hardmode's written feedback after each session is built the same way: what went well, two or three focus areas, and concrete things to try next. Focus areas that keep appearing show up on your dashboard, so you can see when one stops recurring. You can also download a recording of the session in your browser and watch how you handled pauses and follow-ups.

Recall before you review

Deliberate retrieval means trying to recall and apply what you know before checking an answer. It's the opposite of reading a solution and feeling familiar with it. A three-pass routine works for most questions:

1. Cold pass: solve it from scratch under a realistic time limit.
2. Review pass: compare your reasoning with a stronger approach and find the first decision that took you off course.
3. Transfer pass: solve a variation with one meaningful change.

After a basic rate limiter, for example, don't just re-read the token bucket explanation. Rebuild it for a distributed deployment, with per-tenant limits, bursts, or an audit requirement. The system design interview framework gives that practice a repeatable shape: clarify scope, estimate scale, define the API and data model, choose components, discuss bottlenecks, and name trade-offs.

Match practice to the whole loop

An interview loop is the sequence of rounds a company uses to assess a candidate. A typical loop might include a recruiter screen, one or two coding rounds, system design, a technical deep-dive, a behavioural round, sometimes a product round, and finally the offer conversation. Each round asks a different version of the same question: would we trust this person to do well here?

Your practice should reflect that. Read what an interview loop contains, then split your time across the rounds instead of letting coding take every free hour. Strong coders can still have a hard time in a loop by treating the recruiter screen as small talk, giving generic behavioural answers, or rushing through system design.

Behavioural questions: a few stories, many angles

You don't need a separate story for every behavioural prompt. Build an inventory of six to eight real experiences you can adapt:

• A hard technical decision
• A production incident
• A disagreement with a colleague
• A project that changed direction or didn't land
• A time you influenced people without authority
• Delivering something under ambiguity
• Mentoring or leading others
• Improving a process or system

For each, prepare the context, what was at stake, what you did, the result, and what you'd do differently. Then practise the follow-ups that show whether a story is real: who disagreed, what data you used, what you personally contributed. The free STAR story builder turns rough notes into a STAR outline with details worth adding and the follow-ups an interviewer is likely to ask. For the questions themselves, see behavioural interview questions for engineers and the leadership and behavioural round.

System design questions: reasoning, not recitation

A system design question bank should train you to reason about architecture, not recite it. For every prompt, make yourself answer:

• Who are the users, and what are the critical flows?
• What scale is reasonable to assume?
• Which requirements are functional and which aren't?
• What's the simplest design that works?
• Where are the bottlenecks?
• Which data needs strong consistency, and which doesn't?
• How does the system fail, recover, and get observed?
• Which trade-off did you choose on purpose?

When you get to scale, the free capacity estimator works out QPS, storage, bandwidth, and cache size from a few numbers and shows the arithmetic, so you can check your own estimates and practise saying them aloud.

Practise each prompt in layers: a ten-minute outline first, then a full 45-minute design, then a session defending it against follow-ups. That teaches more than drawing full diagrams over and over without looking back at your reasoning. If you want a sequence of prompts to work through, the backend system design question ladder orders them from simpler to harder.

Where mock interviews fit

Question banks build the parts. Mock interviews test whether the parts work together with someone asking questions in real time. They show things a written prompt can't:

• Whether you clarify ambiguous requirements
• Whether your explanation has a clear structure
• Whether you say your trade-offs out loud or make them silently
• Whether you recover when your approach is challenged
• Whether your pacing fits the time
• Whether your behavioural stories hold up under probing

Start them earlier than feels comfortable: once you know the question types for your role, run one a week, and more often as the interview gets closer. For how to set one up so it's worth the time, see how to run a useful mock interview.

Common questions

How many interview questions should I practise?

There's no useful universal number. Aim for reliable performance across the question families that matter for your role. For many people, 20 to 40 technical questions practised properly, with variations and follow-ups, plus regular behavioural and system design rehearsal, is worth more than skimming 150. If you can solve variations and explain your choices, you're ready for more breadth. If not, go deeper before going wider.

Should I read the solution before trying a question?

Not by default. Try it first, even if your attempt is incomplete. The effort of recalling shows you what you actually know and makes the review stick. Give yourself a time box, around 20 to 30 minutes for a coding question depending on difficulty, before looking at hints. Then find the exact point where your reasoning went off course and come back to a variation later.

Should backend engineers spend more time on coding or system design?

Usually both, weighted by level and the company's process. Earlier-career loops often lean on coding fundamentals. Senior backend loops tend to put more weight on architecture, scaling, reliability, ownership, and trade-offs. Read the posting, ask the recruiter how the loop is structured, and split your time to match. Being strong at algorithms doesn't make system design optional.

Can I reuse one behavioural story for several questions?

Yes, and you should. A few detailed, true stories beat many thin ones. The same incident can show ownership in one answer, handling conflict in another, and learning from a setback in a third. Change the emphasis to fit the question rather than forcing the same ending every time.

Your plan for this week

Start with a one-hour setup session instead of another unplanned run of problems:

1. Pick one target role and save the job posting.
2. List the likely rounds: recruiter screen, coding, system design, deep-dive, behavioural.
3. Choose one first-pass question for each round.
4. Start a practice log with columns for what happened, why, and what to try next.
5. Book three focused practice blocks and one full mock round this week.
6. Come back to your toughest question family after two or three days, with a variation rather than the original prompt.
7. After the mock, pick one or two changes for the next session, not ten.

If you want realistic practice for a specific role, Hardmode builds a mock interview loop from the job posting (and your CV, if you add one), or you can run a single round on its own when one skill needs the work. The point isn't to practise everything at once. It's to practise the right thing next.