Seven Habits of Candidates Who Ace the Tech Interview
Most candidates walk into a tech interview underprepared — not because they lack the skills, but because they never made preparation a system. Abel Assefa, in a widely-shared LinkedIn article, laid out seven concrete habits that separate the candidates who get offers from the ones who don’t. The framework is so useful we wanted to walk through it here, in our own words, with notes on how each point lands in the Central Asian tech job market. If you want the original, we’ve linked it at the bottom — go read it.
1. Research the role and the company
A generic candidate says they want “a backend role at a growing company.” A prepared candidate can explain, in one sentence, what the company ships, who pays for it, and why the team is hiring right now. That preparation shows up in how you ask questions, how you frame your answers, and how seriously the interviewer takes you in the first five minutes.
For IT Park residents and Tashkent-based product companies, read the job posting twice, find the company on LinkedIn, and skim one or two recent blog posts or press mentions. Fifteen minutes of homework will put you ahead of most applicants.
2. Prepare for the technical questions
Most technical rounds today pull from a predictable pool: arrays, hash maps, trees, graphs, one or two dynamic-programming patterns, and follow-up questions about time and space complexity. You do not need to grind a thousand problems. You need to solve fifty problems well enough that you can explain your thinking out loud, which is a very different skill from writing a silent solution on paper.
Pair the problem-solving practice with the specific tools mentioned in the job description. If the role asks for Postgres, spend an evening writing non-trivial queries. If it asks for Kubernetes, deploy one thing to a free tier cluster. Depth beats breadth every time.
3. Practice behavioral and situational interviews
The STAR method — Situation, Task, Action, Result — is the single most useful behavioral framework ever invented. The trick is not knowing STAR; it is pre-writing four or five stories from your past work or studies, each mapped to a common prompt (a conflict, a failure, a leadership moment, a difficult technical decision), and rehearsing each story out loud until it runs 90 seconds to two minutes clean.
Interviewers are listening for structure. If your answer rambles, they disengage within thirty seconds — no matter how strong the underlying content is.
4. Master the art of whiteboarding
The whiteboard — or its remote equivalent, a shared code editor like CoderPad or HackerRank — is not really about arriving at the correct answer. It is about letting the interviewer see how you think. Narrate your assumptions. Ask clarifying questions. Write out a small example by hand before you write the function. Say the edge cases out loud even if you don’t handle them all.
The worst thing you can do is solve the problem in silence and then reveal a finished answer. The second worst thing is get stuck and freeze. The best thing is to narrate every step, including the ones where you’re wrong.
5. Sharpen your professional communication
Strong engineers in Uzbekistan and across Central Asia often lose offers not because of what they know, but because of how they explain it. Practice explaining one technical concept a day out loud, as if you were teaching it to a junior. Write a short blog post, or answer a question on a forum. Join an open-source project and submit a pull request with a real description.
This matters doubly if you are interviewing in English as a non-native speaker. Comfort with the language under time pressure is a skill, and like every skill it is built through reps — not through reading about it.
6. Anticipate the interview format
Tech interviews are not a single thing. Depending on the company, you might face any of: a phone screen with a recruiter, a take-home assignment, a live coding round on a shared editor, a pair-programming session, a system-design discussion, a panel interview with multiple engineers, or an on-site loop combining several of the above. Each format rewards a different kind of preparation.
Before the interview, ask the recruiter what the format will be. Most will tell you plainly. Then, practice in that format specifically. A pair-programming round is not the same as a whiteboard round, and preparing for one will not get you ready for the other.
7. Plan for the post-interview
What you do after the interview matters more than most candidates realize. Within 24 hours, send a short personalized thank-you email to each person you spoke with. Reference one specific thing from the conversation — not a generic line. If you don’t get the offer, reply asking for feedback. A surprising number of recruiters will give it, and that feedback compounds across future interviews.
Candidates who treat the interview as a one-shot event plateau quickly. Candidates who treat each interview as data — what worked, what didn’t, what to change — improve at a rate that feels unfair to everyone else.
The one shift that ties it all together
None of the seven habits is clever. What makes them work is treating interview preparation as a practice discipline, the same way an athlete or a musician treats their craft. Read about interviews less. Rehearse them more. The candidates who do the reps, win.
This post is a summary and interpretation of “A Comprehensive Guide to Acing Your Tech Job Interview” by Abel Assefa, published on LinkedIn. The seven-habit framework is his; the commentary and Central Asia framing are ours. Read the original article on LinkedIn.