Which free interview practice resources actually work?

Free resources are enough for serious interview preparation, but a pile of bookmarks is not a practice system. The engineers who improve fastest use each resource for one job: question banks build recognition, AI drills increase repetitions, and live peers expose what happens when another person interrupts, waits, or asks for a justification.

That distinction matters because solving a problem alone and interviewing well are different skills. I have watched capable engineers fail after producing correct code because they never clarified the input, went silent for ten minutes, or defended a shaky design after the interviewer offered a useful hint. More random questions would not have fixed those failures. Rehearsing the whole performance would.

You can build that rehearsal without paying for a course. The cost is that you must choose a small resource stack, keep evidence from every session, and let weak results change next week's calendar.

Build a small stack instead of collecting resources

The best free interview practice resources cover four distinct jobs: learning a pattern, retrieving it under time pressure, explaining it to someone, and reviewing the evidence afterward. No single site does all four equally well. Pick one tool for each job and stay with it long enough to see whether your scores move.

For coding questions, LeetCode and HackerRank both provide free problems. LeetCode's problem catalog, topic filters, discussions, and study plans make it useful for pattern practice. HackerRank's preparation kits group challenges by time horizon and topic, which helps when an empty search box causes decision fatigue. Use whichever interface makes you begin on time. Switching between them every few days creates the pleasant feeling of novelty while erasing continuity.

For live practice, Exponent Practice hosts the peer sessions that began as Pramp. Its published FAQ describes the format clearly: the service matches two engineers, provides the question and shared editor, then has them exchange interviewer and candidate roles. That role swap is more than a fairness mechanism. Interviewing someone else forces you to notice vague prompts, weak hints, and explanations that sound plausible but never state an invariant.

For system design, Donne Martin's open System Design Primer gives you concepts, interview questions, and sample discussions. The repository advises candidates to start broad, then go deeper according to role and available time. I agree with that order. Reading every cache and database detail before attempting a design is a common way to postpone the uncomfortable part, which is making and defending choices with incomplete information.

Your stack can therefore be simple:

• one coding bank, either LeetCode or HackerRank;
• one live peer venue, such as Exponent Practice or a dependable study partner;
• one conversational AI tool for short drills;
• one plain document for your log and scorecard.

Do not judge the stack by the number of questions available. Judge it by whether it produces a timed attempt, spoken reasoning, outside feedback, and a recorded correction every week.

Choose the programming language before you start the plan. Use the language you can explain and debug under pressure, unless the employer requires another one. Interview week is a bad time to trade familiar control flow for shorter syntax. Check whether the actual round allows execution, autocomplete, documentation, or personal snippets, then practice with the same constraints at least once a week.

Browser editors deserve a rehearsal too. Learn how the platform runs tests, displays errors, and handles input before a scored assessment. If the company names its assessment platform, use that platform's public sample test. Losing five minutes to an unfamiliar run button is preventable, and it tells an interviewer nothing useful about your engineering ability.

Match the physical conditions once before the first real round. Use the same computer, microphone, camera position, keyboard, and network location. Share the intended window, silence notifications, and keep a paper backup for rough notes if the format permits it. This is not glamorous practice, but interview performance includes operating the room you chose.

Run that rehearsal with another person on the call. Ask whether your voice cuts out while you type, whether the shared text is readable, and whether looking at a second screen makes you appear distracted. Fix the setup, then stop thinking about it. Equipment checks should remove uncertainty from practice, not become a ritual you repeat instead of solving problems.

Peer practice reveals failures that private study hides

Schedule a peer interview as soon as you can solve an easy problem while speaking, not after you feel fully prepared. Waiting for confidence reverses cause and effect. Confidence usually arrives after several awkward sessions in which you learn that a pause, a wrong turn, or a hint does not end the interview.

Human practice tests social and operational behavior that a question bank cannot measure. Does your opening question reduce ambiguity? Can the interviewer tell which approach you rejected and why? When your first solution fails an example, do you recover calmly or start rewriting without a plan? Do you hear a hint, or are you too busy protecting the answer you already chose?

The peer format has limits. Your partner may be inexperienced, overly generous, or unfamiliar with the role you want. Treat one person's verdict as an observation, not a hiring decision. Ask for behavioral evidence: where did I go quiet, which assumption stayed unstated, when did the explanation become hard to follow, and what part of the code could you not verify? "Good job" is friendly but useless.

Prepare properly when you take the interviewer role. Exponent Practice sends the interviewer the question, solution, and hints in advance. Solve it, identify two likely wrong paths, and decide what evidence would justify a hint. A careless interviewer wastes another engineer's session and misses half the learning available in the exchange.

If matching platforms do not work in your time zone, create a two-person practice pact. Each person brings one problem they have solved, interviews for 35 minutes, then gives ten minutes of evidence based feedback. Swap roles at the next meeting rather than doubling the length of one evening. A tired second interview often produces worse feedback than a fresh session two days later.

Plan for a cancellation without lowering the standard. Keep an AI drill or a solo recording ready for the same time block, but book another human session rather than declaring the substitution equivalent. The backup preserves the habit. It does not reproduce the unpredictability of a person who misunderstands you, changes direction, or simply waits.

Record the call only with explicit consent. You do not need video to diagnose most issues. A shared editor snapshot, the final code, and notes with timestamps are usually enough. The aim is to observe behavior, not create an archive of your partner.

AI drills are useful when the model cannot rescue you

Use AI for repetition and interruption, not as an answer dispenser. A model can generate follow-up questions, challenge an assumption, run a behavioral role play, and compare your final explanation with a rubric. It is especially useful for a 15 minute drill when no peer is available. It is much less useful when it writes the solution after your first pause.

Set the rules before the drill. The following practice contract works with a text or voice assistant and prevents the common failure where the model turns into a tutor halfway through the interview:

Act as an interviewer for a [role and level] interview.
Use this job description: [paste a redacted summary].
Run one [coding, system design, or behavioral] question for 25 minutes.
Ask one question at a time. Do not reveal a solution or suggest an approach.
If I am silent, wait. Give a hint only when I explicitly request one.
Challenge one assumption and ask one follow-up based on my answer.
At the end, score: clarification, reasoning, correctness, communication,
and recovery. Cite a moment from my answer for every score.
Then ask me to produce the improved answer before showing your version.

For a coding drill, paste the problem but keep the reference solution out of the conversation. Use your normal editor, share only the code you would have produced in the interview, and require the model to test it against edge cases after time expires. For system design, ask it to play a skeptical interviewer who changes one constraint. For behavioral practice, use voice if available so you cannot quietly edit every sentence before sending it.

AI feedback is a hypothesis. Models can reward polished nonsense, miss a concurrency bug, or invent a concern that the prompt never supported. Verify technical claims against documentation or by running the code. Compare behavioral feedback across several attempts and keep only recurring observations that you can locate in the transcript.

Protect private information. Remove company names, customer data, internal architecture details, interviewer names, and unreleased job material before pasting anything. A job description is usually public, but your employer's incident story is not practice fodder. Replace identifying details while preserving the decision and result you need to rehearse.

End the session before requesting a model answer. First write your own correction in a few sentences and identify the earliest moment when a better decision was available. Then compare. If you read the polished answer immediately, recognition creates a false sense that you could have produced it. The blank page on the next day gives a more honest result.

Question banks should teach selection, not memorization

A question bank works when it helps you recognize a family of problems and select an approach. It fails when you memorize a sequence of submissions and mistake familiarity for recall. Seeing "two sum" and instantly remembering the final code proves little if a new constraint makes the stored answer invalid.

Start from the interview loop, not a universal list. A junior backend candidate may need arrays, hash maps, trees, graph traversal, and basic SQL. A senior backend candidate also needs design tradeoffs, failure handling, data consistency, and stories about technical judgment. Frontend, data, mobile, infrastructure, and engineering management loops each shift the mix again. Ask the recruiter for the round types and permitted languages. That is ordinary preparation, not gaming the process.

Choose a bounded set such as a published study plan or preparation kit. HackerRank offers one week, one month, and three month kits, while LeetCode publishes topic based study plans. A bounded set stops the daily argument about what to solve. It also makes completion and review visible.

Sample the set before committing. Take one question from several major topics with a 25 minute limit and no hints. The results tell you whether you need a fundamentals pass or mixed practice. If you cannot implement tree traversal at all, study it directly. If you know the traversal but fail to notice when a problem needs it, mixing topics will do more good than another labeled tree worksheet.

For each new coding problem, classify it after the attempt, not before. Write down the signal that should have pointed toward the technique: repeated membership checks suggested a hash map, an ordered answer space suggested binary search, or overlapping subproblems suggested dynamic programming. Then change one constraint and explain whether the same technique survives. This turns a solved question into a reusable decision rule.

Do not grind hard questions because they look serious. Interview difficulty depends on the company and role, but many failures happen on ordinary problems under communication pressure. Spend most sessions at a level where you can finish, test, and explain. Use a harder problem occasionally to observe how you scope, ask for help, and protect correctness when completion is unlikely.

Company tagged lists can help shortly before a known interview, but they are often incomplete, stale, or behind a paid tier. Treat them as a small adjustment after you have broad coverage. Memorizing reported questions leaves you brittle when an interviewer changes the wording, data shape, or follow-up.

Review the failure category before solving again

Every attempt should end with a diagnosis, because "could not solve" hides several different failures. You may lack the underlying concept, fail to recognize a familiar pattern, choose a viable approach but implement it badly, or solve correctly while communicating poorly. Each category needs a different next session.

Use five scores from 0 to 2: clarification, approach, execution, verification, and communication. A zero means the behavior was absent or wrong. A one means it appeared after a hint or remained incomplete. A two means the interviewer could follow and trust it without rescue. Keep the scoring harsh and concrete.

Under each score, save one piece of evidence. "Communication: 1" means little. "Communication: 1, silent from minute 08:10 to 13:40 while replacing the loop" tells you exactly what to rehearse. For an AI drill, take evidence from the transcript. For a peer session, ask your partner to name the moment before either of you discusses an overall impression.

Map the lowest score to the next action. A concept gap calls for reading and two untimed examples. A recognition gap calls for mixed problems where you write only the approach. An execution gap calls for implementing a known solution without autocomplete. A verification gap calls for stating invariants and testing edge cases aloud. A communication gap calls for a short live or voice drill, not another silent problem.

Reattempt the same question after enough time has passed for recall to become effortful. On the reattempt, begin from a blank editor and explain why the approach fits before writing code. If you reproduce syntax from memory but cannot answer a changed constraint, the question is not learned.

Track trends by category, not a vanity total of solved problems. Ten submissions can conceal ten identical mistakes. Three sessions that move verification from zero to two show an actual change in interview behavior.

A weekly schedule should alternate learning and pressure

A useful weekly schedule fits around work and repeats the full interview cycle. Five focused hours beat an ambitious plan that collapses after three days. The schedule below assumes a working engineer with six weeks or more before interviews; reduce the duration of sessions before removing review.

Monday, 45 min: learn one pattern and change one constraint
Tuesday, 45 min: solve two mixed questions, with one timed
Wednesday, 30 min: run an AI voice drill and revise the answer
Thursday, 45 min: reattempt one miss and review two old patterns
Saturday, 75 min: complete one peer mock and give feedback
Sunday, 20 min: review the log and book four sessions

Monday adds a concept. Tuesday tests retrieval before the idea feels comfortable. Wednesday isolates speaking and follow-up questions. Thursday uses spacing to expose shallow memory. Saturday adds human uncertainty, and Sunday turns the week's evidence into calendar changes.

Keep Friday empty. Recovery protects Saturday's mock, and an open day absorbs a missed weekday without pushing every session forward. If your schedule includes a real interview, replace the peer mock and lower the volume for the preceding 24 hours.

Use appointments, not intentions. Put the problem source, the expected duration, and the session type in each calendar entry. Book the peer first because another person's availability is the hardest part to move. When a weekday session slips, use Friday for that one session and leave the rest of the plan in place. Constantly rescheduling the entire week turns planning into its own hobby.

The plan compounds because errors return in a different form. A missed graph traversal becomes an untimed review, then a mixed timed problem, then an explanation under interruption. You are not merely repeating the same question. You are increasing the conditions under which you can retrieve and defend the idea.

When you have only two weeks, keep the same alternation but narrow the question set to the confirmed rounds. Run two peer mocks each week if you can recover between them. When you have three months, resist adding daily hours. Add spacing, deeper design practice, and periodic cold sessions instead.

Behavioral and system design rounds need their own evidence

Prepare behavioral and system design answers as decisions, not speeches. Candidates often spend nearly all their time on coding because a judge returns a clear result. The other rounds feel subjective, so they postpone them. Senior candidates pay heavily for that imbalance because judgment and communication often carry more weight in their loops.

For behavioral preparation, build a story bank around situations you actually handled: disagreement, failure, ambiguous ownership, a tradeoff, feedback, and a result you can explain without inflating it. Write only the situation, your decision, two actions, the observed result, and what you would change. Then practice answering different prompts from the same facts. A memorized monologue breaks when the interviewer asks about your personal contribution or challenges the result.

Ask an AI interviewer or peer to interrupt with specific follow-ups. What alternatives did you reject? Who disagreed? What did you measure? Which part was yours? What happened after the immediate fix? If the story cannot survive those questions, repair the facts and reasoning rather than polishing the opening.

For system design, use a consistent flow but do not recite a template. Establish users and constraints, estimate the load only where it changes a choice, draw the main data path, define interfaces and storage, then examine failure and scaling. The System Design Primer calls the interview an open conversation that the candidate is expected to lead. That is accurate, but leading does not mean talking continuously. It means making the next uncertainty explicit and inviting correction before you build on it.

Keep a photo or exported copy of each final design with three annotations: the largest untested assumption, the first bottleneck, and one rejected alternative. On the next attempt, change a constraint such as write volume, regional availability, or privacy. A design you understand can change without collapsing into a completely new diagram.

Question banks supply prompts for these rounds, but the artifact you review is different. Coding leaves executable output. Behavioral practice leaves claims and evidence. System design leaves decisions and tradeoffs. Score each round on the behavior it actually demands.

Free does not mean unlimited or private

Verify the current limits before you build a calendar around any platform. Free access can require an account, restrict particular features, or change when a product moves. A resource that is free today may still cost attention, personal data, or scheduling flexibility.

The Pramp site now directs new sessions to Exponent Practice and states that peer practice remains free. Its model depends on participants interviewing each other, so your payment is time and reciprocity. HackerRank's current Community documentation lists one free software engineer coding mock and one free technical screen mock, each available once, while additional AI mocks use purchased credits. That makes the free attempts useful as checkpoints, not the foundation of a six week plan.

LeetCode and HackerRank both mix free material with paid features. You do not need company tags, premium editorials, or unlimited AI sessions to build the practice loop in this article. A free problem, a timer, a blank editor, and a peer can reproduce most of the behavior that determines the interview. Paid convenience may reduce search and scheduling effort, but it cannot perform the repetitions for you.

Read privacy and retention controls before putting resumes, transcripts, or job details into an AI tool. ChatGPT, for example, provides voice conversations to logged in users, produces a transcript after a voice session, and exposes data controls. Availability and usage limits can change. Regardless of the tool, redact sensitive material and delete practice conversations you do not want to retain.

There is also an accessibility cost. Live video, fast spoken English, whiteboard drawing, or a particular editor may create friction unrelated to engineering ability. Use practice to identify accommodations you need, then ask the recruiter early enough for the company to arrange them. Do not spend weeks training around an avoidable barrier and hope the interview format changes on the day.

Paid help is worth considering only after diagnosis

Pay for interview coaching when you can name the bottleneck and the service directly addresses it. "I need accountability" is usually solvable with booked peer sessions. "I have two senior system design loops next week and nobody qualified will challenge my tradeoffs" is a clear case where an experienced interviewer may save time.

Professional mocks can provide calibrated feedback, role specific depth, and reliable scheduling. Courses can organize a broad syllabus for someone who keeps losing the thread. Paid question access can be convenient for a narrow company search. None of those purchases fixes avoidance, poor review, or silence under pressure unless the format makes you practice those behaviors.

Do not buy a large package before one diagnostic session. Bring your score log and ask what the coach observed that your existing evidence missed. Afterward, require a concrete correction and a way to test it. If the advice is only "practice more" or "be confident," spend the next hour with a peer instead.

Founders hiring engineers should apply the same discipline to their own interview process. A candidate cannot compensate for an inconsistent rubric, duplicated rounds, or interviewers who never calibrate. I use this evidence first approach in Team & AI Audits at oleg.is because reducing engineering cost starts with finding which work and which judgments actually require a person.

For candidates, the immediate test is simpler. Open next week's calendar. It should contain one learning session, one cold timed attempt, one spoken drill, one reattempt, and one human mock. If it contains seven identical problem sessions, change it before solving anything else.