The best technical interview preparation starts with the job posting, not a random list of problems. Find out which skills the role needs and what format the interview takes. Then study the topics that format will test, practice solving problems out loud, and review every mistake. This guide walks through that process in order, so you can spend your hours on what will actually be asked.
TL;DR
- Read the job description first and ask the recruiter what the interview will cover. The mix of questions changes from role to role.
- Review core computer science: data structures, algorithms, complexity, and the topics the role names, such as databases or distributed systems.
- Practice talking while you solve. Interviewers are judging your reasoning and communication, not only your final code.
- Rehearse each format you will face: live coding, take-home work, system design, and a conversation about your own projects.
- Keep a mistake log, set a weekly schedule you can sustain, and prepare questions of your own for the interviewer.
Table of Contents
- Start with the job description and the format
- What to study, and in what order
- Practice questions by topic
- How to work through a coding problem out loud
- Prepare for each format you will face
- Prepare to talk about your own work
- Build a study plan you can keep
- Manage nerves on the day
- Our perspective: preparation should follow the job, not the internet
- Put the plan into practice with WorkHunt
- FAQ
- Sources
Start with the job description and the format
Most candidates open a problem set on day one. A better first move is to read the posting line by line and underline every technology, skill and responsibility. Those words tell you what the team cares about. A posting that stresses data pipelines points to a different interview than one that stresses mobile interfaces.
Then find out how the process works. The Colorado State University career center guidance on technical interviews recommends reviewing the job description for required skills, checking the company's careers page for details on the interview format, and asking the recruiter when the process is unclear. Recruiters get this question all the time, and asking it does not count against you.
Amazon's own software-development interview guidance makes the same point: ask your recruiter which subjects and skills are most likely to be assessed, because the interview mix varies by role.
A good list of questions for the recruiter:
- How many rounds are there, and how long is each?
- Is there a phone screen, an online assessment, a take-home project, or all three?
- Will I code in a shared editor, a browser tool, or on a whiteboard?
- Which languages are allowed?
- Is there a system-design round, and does it apply to my level?
- Who will I meet, and what are their roles?
Write the answers down. They become the outline of your study plan.
If you want to turn a posting into a list of likely questions quickly, our guide on interview prep from a job description shows how to predict what will come up before you start studying.
What to study, and in what order
You cannot review all of computer science in a few weeks, so prioritize. Amazon lists the technical areas it expects software candidates to review: programming language, data structures, algorithms, coding, object-oriented design, databases, distributed computing, operating systems, internet topics, and general machine learning and artificial intelligence, as described on its software development interview topics page. That list is broad on purpose. Your recruiter's answer and the job description tell you which parts matter for you.
A sensible order of priority, based on how often each area tends to come up in coding rounds:
| Priority | Area | What to be able to do |
|---|---|---|
| 1 | Data structures and algorithms | Choose the right structure, implement it, and explain the trade-offs |
| 2 | Complexity analysis | State time and space cost for your solution and for alternatives |
| 3 | Your main language | Write clean, idiomatic code without leaning on an autocomplete |
| 4 | Role-specific topics | Databases, concurrency, APIs, front-end rendering, or whatever the posting stresses |
| 5 | Design | Object-oriented design for mid-level roles, system design for senior ones |
| 6 | Your own projects | Explain decisions, failures and results in plain language |
The order of the first two rows matches what academic curricula treat as essential. ACM's CS2023 curriculum lists fundamental data structures and algorithms, algorithmic strategies, and complexity analysis as core knowledge areas. If you studied computer science, this is a refresher. If you are self-taught or switching careers, it is the foundation to build first.
For backend and infrastructure roles, add concurrency and distributed systems. The CS2023 core for parallel and distributed computing covers communication, shared memory, data stores, safety, liveness, performance, concurrency errors, and distributed algorithms. You do not need to master all of it, but you should be able to explain a race condition and how you would prevent one.
Practice questions by topic
Good practice is organized by pattern, not by the order problems happen to appear. The table of contents of a well-known interview book, listed on the ACM Digital Library page for Elements of Programming Interviews, is a handy map of the territory: primitive types, arrays and strings, linked lists, stacks and queues, binary trees, heaps, searching, hash tables, sorting, binary search trees, algorithmic techniques, graph algorithms, intractability, parallel computing, design problems, probability, and discrete mathematics.
Use that list as a checklist. For each area, aim to solve a handful of problems of increasing difficulty. Here are the kinds of questions to expect:
- Arrays and strings: Find duplicates, merge sorted lists, check whether two strings are anagrams.
- Linked lists: Reverse a list, detect a cycle, merge two sorted lists.
- Stacks and queues: Validate balanced brackets, implement a queue with two stacks.
- Hash tables: Count frequencies, find two numbers that sum to a target, group items by a key.
- Trees and graphs: Traverse a binary tree, find the shortest path, detect a cycle in a dependency graph.
- Sorting and searching: Binary search on a rotated array, find the k-th largest element.
- Design problems: Build a rate limiter, an in-memory cache, or a URL shortener.
For role-specific questions, work from the posting. A front-end role might ask you to explain how the browser renders a page or to build a small component. A data role might ask for a SQL query with joins and aggregation. A Java role might ask about collections, memory and concurrency. These questions are less predictable than pure algorithm questions, which is why the job description matters.
A tool that builds practice from the posting can save time here. In WorkHunt, coding practice is generated from the job description and graded instantly, so the questions reflect the role you are applying for rather than a generic set.
How to work through a coding problem out loud
The candidates who do well are rarely the ones who type fastest. They are the ones who make their thinking visible. The Turing School curriculum on analyzing technical challenges lays out a routine you can adopt directly: restate and clarify the problem, consider edge cases and simple test cases, identify a pattern, plan with pseudocode, implement, talk through an example, and evaluate time complexity.
Here is that routine as a script you can rehearse:
- Restate the problem. Say it in your own words. If you misunderstood, you find out in thirty seconds instead of twenty minutes.
- Ask clarifying questions. What are the input sizes? Can values repeat? Can the input be empty? Is the data sorted?
- Work a small example by hand. Pick a simple case and a tricky case. Write them down.
- Name a pattern. Is this a two-pointer problem, a hash-table lookup, a graph traversal, a recursion with memoization? Say your guess aloud, even if you are not sure.
- State a brute-force solution first. Give its complexity, then improve it. This shows you can get a working answer before optimizing.
- Plan in pseudocode. A few lines are enough. Confirm the approach with the interviewer before writing real code.
- Implement. Write clean code, with sensible variable names, and narrate what each block does.
- Test. Walk your example through the code line by line. Fix bugs calmly.
- Evaluate complexity. State time and space cost and mention a trade-off you considered.
This routine also guards against a common failure: jumping into code and getting stuck halfway. Following steps gives you something to say even when you are unsure, and interviewers notice that.
Practice the routine on a timer, speaking aloud as if someone were listening. It feels awkward at first. Record yourself once or twice. You will hear filler words, long silences and skipped steps that you cannot notice while typing.
Prepare for each format you will face
Live coding
In a live round, you solve one or two problems in a shared editor while an engineer watches. Amazon advises candidates to practice coding outside an IDE, since the interview environment will not offer the autocomplete and debugging tools you use every day. Amazon also points to a sample coding challenge so candidates can get comfortable with the assessment setup.
Practical steps: write solutions in a plain text editor, run them by hand in your head, and learn the syntax of your language's core library well enough that you do not need to look things up. Ask the recruiter whether you can run code during the interview.
Take-home assignments
Take-home work rewards a different skill: shipping something small and tidy. Read the brief twice. Note what is required and what is optional. Keep your scope tight, write a short README that explains your choices and trade-offs, include a few tests, and stay within the time the company suggests. Reviewers often compare many submissions, so clarity and a working core beat clever extras.
System design
Senior roles, and some mid-level ones, include a design conversation. Amazon provides a system-design preparation video for candidates, and its guidance for engineering managers says to expect at least one software systems design question and to ask questions to complete and validate the design.
That second point is the most useful habit to copy. Start with requirements: how many users, what read and write patterns, what latency, what consistency. Sketch the main components, then go deeper where the interviewer shows interest. Name trade-offs openly. A design with honest trade-offs beats one that claims to have none.
Prepare to talk about your own work
Many technical interviews include a stretch where you describe past projects. Treat it as seriously as the coding. The Colorado State guidance says employers look for logical problem-solving, clear communication, adaptability, honesty, collaboration, and composure under pressure. Your project stories are where most of those qualities show up.
Pick three projects from your resume and prepare a short account of each:
- The problem: What was broken or missing, and for whom?
- Your part: What you personally built or decided, not what the team did.
- A decision: One technical choice, the alternatives, and why you chose as you did.
- A setback: Something that went wrong and what you changed.
- The result: What improved, with a number if you have an honest one.
Be ready for deep follow-ups. If your resume says you used a message queue, expect to be asked why, what happened when it failed, and what you would do differently. Do not claim tools you cannot discuss. If your resume is out of step with the posting, fix it before the interview: a software engineer resume template is a good place to see how to present projects and skills clearly.
Also prepare questions for the interviewer. The same Colorado State page recommends asking about the technical environment and team structure. Good ones include how the team handles code review, how deployments work, and what the first three months look like.
Build a study plan you can keep
The right schedule depends on your starting point, your deadline, and your job. A plan you follow for six weeks beats a heroic one you drop after four days. Here is a simple template to adapt. It is our suggestion, not a research-backed standard.
| Week | Focus | Output |
|---|---|---|
| 1 | Job description, format, fundamentals review | A topic list and a recruiter answer sheet |
| 2 to 3 | Core data structures, one pattern at a time | Several problems per pattern, solved out loud |
| 4 | Role-specific topics and design basics | Notes on databases, concurrency, or front-end topics as needed |
| 5 | Mixed practice under time limits | Full mock sessions, with review |
| 6 | Project stories, questions for the team, rest | A calm final week |
If you have more time, stretch each phase. If you have less, cut breadth first and keep the mock sessions. Some popular handbooks suggest a roughly three-month plan for thorough preparation, but treat any hours-per-week figure as a starting point and adjust it to your own progress.
Keep a mistake log
After every practice problem, write down what went wrong: a misread requirement, an off-by-one error, a complexity you got wrong, a pattern you did not recognize. Review the log weekly. Repeated entries show you where to focus. Re-solve missed problems a few days later without looking at your notes. If you can solve it cold, you learned it. If not, it goes back in the queue.
Run mock interviews
Solving problems alone is not the same as solving them with someone watching. Do at least a few mock interviews before the real one, with a friend, a colleague, or a tool that simulates the format. Ask for feedback on three things: how clearly you explained your approach, how you handled hints, and how you managed time.
Manage nerves on the day
Nerves are normal, and part of what interviewers observe is composure under pressure. A few habits help:
- Do a dry run of your setup the day before: camera, microphone, editor, internet, a glass of water.
- Sleep matters more than one more problem at midnight.
- When you blank, say so, then return to your routine: restate the problem, work a small example, and try a brute-force approach.
- Treat hints as collaboration, not failure. Using a hint well is a good signal.
- If you make a mistake, name it, fix it, and move on. Spiraling costs more than the error.
After the interview, write down the questions you remember while they are fresh. You will use them if there is a next round, and they will sharpen your next preparation.
Our perspective: preparation should follow the job, not the internet
We built WorkHunt around one belief: most wasted effort in a job search comes from guesswork. Candidates send the same resume to every posting, then study the same generic question lists for every interview. Both habits ignore the one document that tells you what an employer wants.
That is why we generate interview prep from the job posting itself. Paste a link, and the requirements drive the resume edits, the likely questions, the coding practice and the mock interviews. You see each suggested resume change next to your original and approve or revert it, so the final document is still yours. Your master resume stays intact, and your data is not used for AI training.
Our advice for technical interviews follows the same logic. Prepare for this role at this company, practice speaking as much as coding, and measure your progress with feedback instead of feelings. Hours spent on topics the posting never mentions are hours you could have spent on the ones it does.
— CoffeeDrop
Put the plan into practice with WorkHunt
WorkHunt turns a job link into a tailored resume, a matching cover letter, coding practice based on the job description with instant grading, and voice or text mock interviews with performance metrics. It also tracks your applications from first submission to offer, so you always know which interview needs which preparation.
You can start on the free plan, which includes limited features. The Pro plan, from $15 per month, unlocks full tailoring, interview prep, coding practice and application tracking. See the options on the WorkHunt site. For more guides, browse our interview prep articles, or read the broader practical plan for preparing for a job interview for the non-technical rounds.
If you are applying for developer roles, a matching software developer resume template and cover letter example will help you get the interview in the first place.
FAQ
How long does it take to prepare for a technical interview?
It depends on your starting point and the role. A candidate with a strong computer science background might need a few weeks of focused review, while someone changing careers may need several months. Set a schedule you can keep, and judge readiness by how well you solve unseen problems out loud, not by hours logged.
What should I study first?
Start with the job description and a conversation with the recruiter about what will be assessed. Then review data structures, algorithms and complexity analysis, followed by the topics the role names. Amazon's guidance says the interview mix varies by role, so the recruiter's answer should shape your priorities.
Do I need to memorize solutions to practice questions?
No. Memorized answers fall apart when the interviewer changes a detail. Learn patterns instead: what kind of problem calls for a hash table, two pointers, or a graph traversal. Then practice explaining why a pattern fits, which is what interviewers want to hear.
How do I practice when I get nervous speaking while coding?
Speak aloud during every practice session, starting with easy problems so the habit forms without extra pressure. Record a session and listen for silences and skipped steps. Then add mock interviews with another person or a simulator so you get used to being watched.
What if I get stuck in the interview?
Say what you are thinking, restate the problem, and work a small example by hand. Offer a brute-force solution if you cannot see the optimal one yet. Interviewers often give hints, and responding to them well shows that you collaborate.
Sources
- Preparing for Technical Interviews, Colorado State University Career Management Center
- Amazon Software Development Interview Topics
- Amazon SDM Interview Prep
- ACM CS2023: Algorithms and Complexity
- ACM CS2023: Parallel and Distributed Computing core
- Elements of Programming Interviews, ACM Digital Library
- Analyzing Tech Challenges, Turing School curriculum