How to prepare for a technical interview without burning out

Interviewers rarely care whether you remember an obscure function. They want to know four things: whether you understand the fundamentals, whether you can solve a problem you have not seen before, whether you can explain your thinking, and whether you would be pleasant to work with.

So the best preparation is not memorising answers. It is practising how to think out loud and how to work through something unfamiliar without freezing.

Read the job post and list the technologies it names. Then refresh the basics of each one, especially the parts you use without thinking about them.

• For a frontend role: how the browser renders a page, the box model, how state and effects work in your framework, accessibility basics, and how you would debug a slow page.
• For a backend role: how HTTP works, how you design an API, how a database index works, what a transaction is, and how you handle errors and retries.
• For a mobile role: the app lifecycle, how you manage state, how you handle offline use, and how you ship an update to the stores.
• For data and AI roles: how you check that a model or a query result is correct, and how you would explain it to someone who is not technical.

Do not try to learn a whole new framework the week before. Spend your time on what the job actually uses.

Almost every interview includes a question like: tell me about a project you built. Many candidates answer badly because they never practised it.

Pick two projects you know well. For each, be ready to say what problem it solved, what you built, one decision you made and why, one thing that went wrong and how you fixed it, and what you would do differently now.

The question about what went wrong is the one that makes you look senior. Everyone has bugs and bad decisions. Showing that you noticed, fixed and learned from them is a strength.

• Read the problem back in your own words before you write anything. This catches misunderstandings early.
• Ask questions about the inputs, the size of the data and the edge cases. Interviewers like this. It is what real developers do.
• Say your plan before you code it, even in two sentences. If the plan is flawed, the interviewer can steer you before you lose ten minutes.
• Start with a simple version that works, then improve it. A working simple answer beats a half-finished clever one.
• Talk while you work. Silence makes it hard for the interviewer to help you or to see how you think.
• Test your solution with an example, including an empty input and an unusual one.

If you get stuck, say so and describe what you have tried. Asking for a small hint is normal. Pretending to be fine while stuck for ten minutes is worse.

Some companies give a small project to do at home. Treat it like a sample of your real work.

• Read the brief twice and note the time they suggest. Do not spend three days on a task meant for three hours.
• If anything is unclear, ask. Asking is a good sign, not a weakness.
• Write a short README that says how to run it, what you built, what you skipped and why, and what you would do with more time.
• Add a few tests and keep the commit history tidy. Small details like these separate candidates.
• Submit on time, and keep the code simple and readable.

Senior candidates are often asked to design a system, for example a service that sends notifications or a simple job board. There is no single right answer. The interviewer is watching how you reason.

Start by asking what the system must do and how many users it expects. Sketch the main pieces, then talk about the trade-offs: where data lives, what could fail, what you would build first and what you would leave for later. Naming the downsides of your own design shows maturity.

An interview is also your chance to judge them. Prepare three or four real questions.

• What does a typical week look like for this role?
• How do you review code and release changes?
• How does the team communicate when people work in different time zones?
• What would a good first three months look like?
• What is the hardest problem the team is working on right now?

Test your internet, camera and microphone the day before. Close other apps. Have water and a notebook ready. If the interview is remote, a quiet room and a plain background are enough.

Sleep matters more than one more hour of practice. A rested mind solves problems better than a crammed one. And if it goes badly, remember that each interview you do makes the next one easier.