Engineering Interviews
You have 40 interview tabs open and still don't know what to study.
Interview preparation gets worse when everything looks important. The closer the interview gets, the more your calendar should force you to cut.
5 min read
Your interview is in nine days. You have a concurrency article open, a system design course, three Reddit threads, a list of behavioral questions, a half-watched YouTube video and twenty coding problems marked "must redo." If you are on iOS, add Swift, SwiftUI, persistence and whatever WWDC session suddenly looks urgent. If you are on Android, add Kotlin, coroutines, Flow, Compose, lifecycle and another argument about whether the company will ask architecture or algorithms.
Everything looks useful. That is the problem.
You do not have an information shortage. You have more material than the remaining calendar can support, and every evening spent deciding what to study is one less evening actually preparing.
Prioritisation is uncomfortable because it admits you cannot cover everything. The calendar already admitted that for you.
"What could they ask?" is a terrible question
They could ask almost anything. That question creates infinite preparation.
What if they go deep on concurrency? What if system design dominates the loop? What if there is LeetCode? What if they ask persistence, performance, platform internals or the framework you have not touched in two years?
You can keep adding material forever. The useful question is narrower:
What can still materially change the outcome before the interview?
If the interview is three months away, build depth. If it is three weeks away, prioritise. If it is next Tuesday, triage. If it is tomorrow, stop pretending you are going to rebuild your engineering career overnight.
The closer the interview gets, the smaller the preparation surface should become.
Your last interviews are better data than another generic checklist
If you have interviewed recently, use the evidence.
Where did the process end? Did you fail before the technical rounds started? Did you pass coding and fall apart in system design? Did the interviewer keep drilling into concurrency because your first answer never became precise? Did your behavioral answers get weak the moment the question moved from what happened to what you personally decided? Did you survive the loop and still get downlevelled?
Those patterns matter more than another "Top 100 interview questions" page.
You can spend weeks making your strongest round even stronger because it is the part you enjoy practising. A candidate who likes algorithms keeps solving algorithms. An architect keeps reading system design. Someone comfortable with platform trivia keeps collecting more trivia.
It feels productive because you are getting better at something.
It may not change the outcome at all.
Preparation should react to the failure you actually have, not the one you prefer working on.
Stop studying subjects. Start repairing failures.
"I need to learn Swift concurrency" is too big.
"I cannot explain cancellation, isolation and ordering once the interviewer changes the happy path" is useful.
"I need Android architecture" is too big.
"I get confused about state ownership across Compose, ViewModel, process death and persistence" is useful.
"I need system design" is too big.
"I can draw the happy-path architecture, but I fall apart when offline state, retries and conflict resolution enter the conversation" is useful.
The first version gives you a syllabus. The second gives you something you can attack tonight.
Good preparation gets narrower as you learn more about the weakness. That is how you stop opening new tabs and start closing them.
A real preparation plan has casualties
Engineers hate deleting topics because removing something feels irresponsible. You cut one subject and immediately imagine the interviewer asking exactly that question, so you put it back. Soon the plan contains everything, which means it contains no priorities at all.
Maybe system design is weak, the role is Senior, and you know there is a dedicated design round. That deserves time. Maybe you have passed coding comfortably in your last five loops but still spend every evening on coding puzzles because the progress is easy to measure. That probably does not.
Maybe your interview is in four days and you discover a platform area that would take two weeks to understand properly. You may have to accept that risk and spend those four days repairing something you can actually move.
That is not laziness. It is what engineers do everywhere else when resources are limited and a deadline is real.
The goal is not to finish the syllabus. The goal is to change the hiring decision.
The night before is not for heroics
This is where otherwise sensible engineers start behaving strangely.
The interview is tomorrow, so at 11:30 PM one Reddit comment sends them into a topic they have never studied before. Two hours later they are tired, anxious and still do not understand it.
There is a point where another hour of study produces less value than sleep. There is a point where reviewing five strong answers is better than discovering twenty new weak ones. There is also a point where the correct preparation decision is closing the laptop.
A deadline should force those decisions earlier, not at 2 AM.
When the interview is close, your job is not to become a different engineer. It is to make the engineer you already are easier to retrieve under pressure.
This is why the 24-Hour books exist
I built The 24-Hour iOS Interview Answer Book and The 24-Hour Android Interview Answer Book for a different problem from a full interview curriculum.
The 24-Hour books are for the point where time itself has become part of the problem. You need current questions, useful answer depth, follow-ups and a way to concentrate on what can still change the room you are about to enter.
They will not make you an expert overnight. Nothing will.
What they can do is stop you wasting the remaining hours pretending every weakness deserves equal time. For iOS, that means getting quickly to the questions and follow-ups that matter in the modern iOS loop. For Android, it means doing the same across the current Android interview surface.
You do not need another forty tabs. You need a decision about what deserves the next hour, and the discipline to let the rest wait.
Your interview date should delete things from your study plan.
