Start with the interview you actually have
Preparing for a better engineering role can easily become a second full-time job. You collect problem lists, buy a design course and watch other people solve questions. A week later, you have more material but little evidence that you can perform under interview conditions. Start by making the task smaller: identify the next assessment, attempt it once, and use the result to decide what to practise.
Amazon’s own preparation page recommends asking your recruiting contact about the subjects and skills you will be assessed on. It emphasizes applying fundamentals rather than memorizing detail. That is employer-specific guidance, not a universal interview format. Ask your recruiter about the duration, coding environment, permitted language, design expectations and whether a project discussion is included.
The plan below is Opened’s suggested practice routine. It is not a validated hiring formula or a promise of an offer. A fresher with an online assessment next week and an experienced backend engineer facing a design round need different allocations of the same limited time.
Sources: Amazon: software development interview topics; Tech Interview Handbook: interview formats
Run a baseline before choosing a course
Set aside one uninterrupted session. Pick an unfamiliar coding problem at a level relevant to the role, use the language you intend to interview in, and work without the solution or AI assistance. Say your assumptions aloud. When time ends, keep the unfinished work: it is more informative than a polished solution copied afterward.
Review the attempt in four parts. Did you understand the contract? Could you propose a correct approach? Could you implement it? Did you test and explain it? A failure in the second part needs different practice from a correct algorithm derailed by unfamiliar library syntax. Write one specific next action, such as “practise maintaining a sliding-window invariant,” rather than “get better at arrays.”
For an experienced role, add a short design baseline. Explain a service you know, including its data model and one failure mode. For an internship, use a project walkthrough instead: demonstrate what you built, the decisions you made and a bug you can explain. Neither exercise requires a paid subscription.
Read the diagram
- Attempt. Use the expected interview format and record where you got stuck.
- Target the weakness. Distinguish reasoning, implementation and explaining the trade-off.
- Recheck. Try a fresh problem without hints, then adjust the practice.
Choose resources by the job they do
Tech Interview Handbook is useful for understanding the different interview formats and organizing preparation. Use it to build a checklist, then return to doing problems. LeetCode can supply a problem bank; the important choice is a coherent topic sequence, not the largest possible list. Read current access terms before paying for any library.
Hello Interview’s delivery framework is useful when you need a structure for system-design discussion: clarify requirements, define the interface and build toward a design that can be examined in detail. Use the framework to practise your explanation. Reading someone else’s finished architecture is not equivalent to producing a defensible design yourself.
Keep one primary resource per skill for the first week. If you change resources, identify the gap the replacement solves: better explanations, a missing topic or realistic feedback. A new subscription should not be the default response to an uncomfortable practice session. Check the employer’s preparation material before buying generic company-specific bundles.
Sources: Tech Interview Handbook: interview formats; Hello Interview: system design delivery framework; LeetCode problem library
A coding exercise that exposes real understanding
Consider this practice prompt: given a sequence of event IDs, return the first ID that appears more than once. Before coding, clarify whether “first” means the earliest second occurrence or the repeated value whose first occurrence was earliest. For [A, B, B, A], those interpretations produce B and A respectively. The algorithm cannot be judged until the contract is clear.
For the earliest second occurrence, scan from left to right while keeping a set of IDs already seen. If an ID is in the set, return it; otherwise add it. The invariant is that the set contains exactly the IDs before the current position. With expected constant-time hash-set operations, this uses expected O(n) time and O(n) extra space. Explain what you return when nothing repeats.
Now test empty input, a single item, adjacent duplicates and a repeat at the final position. Ask what changes if input arrives as an unbounded stream or memory is limited. You do not need to solve every extension during the first attempt. The point is to connect the requirement, invariant, implementation and tests instead of recognizing a familiar pattern and rushing into code.
After reading a solution, close it and reconstruct the reasoning. On a later session, attempt a variation. Record whether you solved it independently, needed a small hint or relied on the full answer. Counting all three as “completed” hides the skill you are trying to develop.
Make system design a sequence of decisions
A system-design answer becomes difficult to evaluate when it starts with a shopping list of databases and queues. Start with the user action and the required behavior. For a notification service, ask who creates notifications, which channels matter, what latency is acceptable and whether duplicate delivery is tolerable. State assumptions explicitly when the interviewer leaves a choice to you.
Draw the smallest working path: request, durable record, worker, delivery provider and status update. Then discuss a failure. If the provider accepted a notification but your worker lost the response, a blind retry may send it twice. That gives you a reason to discuss idempotency, retry policy and reconciliation. The components now answer a requirement rather than decorate the diagram.
Hello Interview offers a structure for moving from requirements to deeper investigation. Treat that as scaffolding, not a script. For every component you introduce, be ready to answer what it stores, which failure it handles and what new operational burden it adds. A junior candidate can explain a small design carefully; a senior candidate should be prepared to discuss migration, observability and the consequences of being wrong.
A four-week plan with concrete outputs
Week one is diagnosis. Confirm the assessment format, run the baseline, choose two weak topics and make a resource shortlist. End the week with an error log, one project outline and a realistic schedule. If you have only four hours a week, budget four hours; a plan built around imaginary free time is difficult to sustain.
Week two is targeted practice. Alternate unfamiliar exercises with reconstruction of earlier mistakes. Reserve part of each session for tests and explanation, even if that reduces the number of problems you attempt. Your output should be a small set of solutions you can justify without looking at notes.
Week three is integration. Mix topics so the exercise no longer announces the technique. Add design or project discussions appropriate to your level. Prepare a few factual stories about ownership, disagreement and learning. Ask a peer to interrupt with clarification questions rather than waiting politely for a monologue.
Week four is rehearsal and repair. Run timed sessions in the expected environment. Review whether you lose time understanding the prompt, choosing an approach, typing or communicating. Spend the next session on the largest recurring problem. Do not fill the final evening with new material; check your setup and leave room to rest.
Adapt for freshers, switchers and a short deadline
For internships and graduate roles, project understanding can make your experience concrete. Be able to explain your schema, a request from UI to database, how you tested it and one limitation. A small working project with clear ownership is easier to discuss than a long list of technologies you barely used. Ask which fundamentals the assessment covers rather than assuming advanced distributed systems will be required.
For an engineer changing companies, translate existing work into decisions: why an API changed, how a rollout was made safe, what an incident taught you. Avoid equating years employed with readiness for a particular interview. You may need coding practice even if your day job is technically demanding, or operational examples even if algorithms come easily.
If the interview is in seven days, compress the scope rather than claiming to compress a full curriculum. Confirm the format, repair the biggest baseline weakness, rehearse your strongest project and run one realistic mock. Use the mock to identify what to clarify with the recruiter or revise before the interview.
Measure readiness without inventing a success score
Look for repeatable behaviors: you ask relevant questions, produce a correct basic solution, identify edge cases, explain complexity and recover when challenged. Keep the error log short enough to use. “Forgot the no-result case twice” is actionable; “not confident” is a feeling worth acknowledging but not a training task.
Preparation does not guarantee an offer, and an interview result is not a complete measure of engineering ability. Use feedback to refine the next cycle while continuing to seek roles that suit your experience. Opened can help surface those opportunities; this guide helps you prepare to discuss them once an employer invites you.