Seven days is enough to become meaningfully better prepared for a tech interview if you work from evidence and priorities. It is not enough to relearn an entire profession. Your task is to understand the role, refresh the skills most likely to be assessed, select honest examples from your experience, and make your thinking easy to follow.
This plan fits software engineering, data, product, design, QA, and related roles. Adjust the technical exercises to the interview format you have been given. If the recruiter has not explained the process, ask for the stages, duration, participants, tools, and whether any live exercise, portfolio review, take-home task, or system-design session is expected.
Before day one: collect the source material
Create one preparation document containing:
- the exact vacancy text;
- the CV and application you submitted;
- names and roles of interviewers, if known;
- the interview format and schedule;
- your company research links;
- questions you want answered;
- stories and technical topics to practise.
Do not prepare from memory alone. Interviewers may ask about a line in the specific CV version you sent months ago.
Day 1: decode the role
Read the vacancy and separate signals into four groups.
Outcomes
What must this person achieve? Examples include reducing deployment risk, growing activation, improving data reliability, leading a migration, or building a new team capability.
Skills
Which tools, methods, and domain knowledge are required? Distinguish core requirements from a long wish list.
Scope
Look for seniority signals: ownership, ambiguity, cross-team influence, mentoring, architectural decisions, customer contact, or accountability for metrics.
Constraints
Record location, time zones, travel, language, on-call work, contract type, security clearance, and work authorization.
Create a table with three columns: requirement, my evidence, and open question. Use only real evidence. If a gap is genuine, prepare to explain adjacent experience and how you would learn rather than pretending the gap does not exist.
Research the company’s product, customer, business model, stage, competitors, and recent important changes. For a public company, investor materials can clarify priorities. For a smaller company, product documentation, changelogs, engineering posts, and leadership interviews may be more informative.
Finish day one by writing a two-minute answer to “Tell me about yourself” that connects your past, present strengths, and reason for this role.
Day 2: build your evidence bank
Prepare six to eight stories that can answer multiple behavioral questions. A balanced bank might include:
- your strongest relevant accomplishment;
- a difficult technical or product decision;
- a conflict or disagreement;
- a mistake and what changed afterward;
- work under ambiguity;
- cross-functional collaboration;
- helping another person grow;
- managing competing priorities.
Use STAR—Situation, Task, Action, Result—but spend most time on Action. Interviewers need to know what you observed, decided, communicated, and changed.
A useful story outline:
- Situation: two or three sentences of context.
- Task: your responsibility and the constraint.
- Action: the alternatives, your decision, execution, and collaboration.
- Result: measurable outcome, feedback, or concrete learning.
- Reflection: what you would repeat or do differently now.
Replace vague language with observable detail. “We improved performance” becomes “I profiled the checkout bundle, proposed route-level splitting, coordinated the rollout with analytics, and reduced median interactive time from 4.1 to 2.7 seconds.” Use numbers only when you can explain where they came from.
Practise each story in a ninety-second and a three-minute version. The short version protects you from rambling; the longer version gives room for follow-up questions.
Day 3: refresh the technical foundations
Use the role matrix from day one. Rank topics by likelihood × importance × weakness. Work on the highest scores first.
For software engineering, that might mean:
- language fundamentals and common failure modes;
- data structures appropriate to the role;
- testing and debugging;
- APIs, databases, concurrency, or browser behavior;
- architecture trade-offs at the expected seniority;
- security, reliability, observability, and performance.
For data roles, priorities may include SQL, experiment design, statistics, data quality, modeling choices, and communicating uncertainty. For product or design, practise product diagnosis, prioritization, research decisions, metrics, critique, and stakeholder trade-offs.
Use active recall. Close the documentation and explain a concept aloud. Solve a small representative problem, then review where your reasoning became unclear. Avoid spending the entire day passively watching tutorials.
Prepare a debugging script you can use under pressure:
- Restate the symptom and expected behavior.
- Clarify constraints and available evidence.
- Form a small number of hypotheses.
- Choose the cheapest discriminating test.
- Narrow the search systematically.
- Fix the root cause and discuss prevention.
Interviewers often evaluate the structure of your investigation, not just whether you recognize the bug instantly.
Day 4: practise the actual format
Match practice to the interview.
Live coding
Use the same language and, where possible, a similar editor. Practise narrating without turning every keystroke into commentary:
- clarify inputs and constraints;
- state a simple approach;
- write a correct baseline;
- test normal and edge cases;
- analyze complexity;
- improve only when needed.
If you become stuck, say what you know, identify the uncertainty, and propose the next test. Silent guessing is difficult to evaluate.
System design
Practise a repeatable structure:
- Clarify users, scale, and success criteria.
- Define functional and non-functional requirements.
- Sketch interfaces and core data.
- Propose a simple end-to-end design.
- Identify bottlenecks and failure modes.
- Discuss trade-offs, observability, security, and evolution.
Do not jump directly to fashionable infrastructure. Tie each component to a requirement.
Portfolio or case study
Tell a decision story, not a gallery tour. Explain the problem, your role, constraints, evidence, alternatives, trade-offs, outcome, and learning. Be precise about what teammates contributed.
Take-home exercise
Clarify time expectations and submission format. Prioritize correctness, a clear README, sensible tests, and stated trade-offs. Do not build an imaginary production platform when the task asks for a small prototype.
Day 5: run a realistic mock interview
Ask a trusted peer to conduct a forty-five to sixty-minute session. Give them the vacancy and format, but not your prepared answers. Record the session with everyone’s consent.
Evaluate:
- Was the opening answer relevant and concise?
- Did you clarify ambiguous questions?
- Could the listener distinguish your contribution from the team’s?
- Did your technical reasoning have a clear sequence?
- Were results and trade-offs concrete?
- Did you recover calmly after uncertainty?
- Which answer ran too long?
Repeat the two weakest segments immediately. Improvement comes from a short feedback loop, not from collecting a long list of flaws.
If no partner is available, record yourself answering five questions. Listening back is uncomfortable and extremely informative. Notice filler words, unexplained acronyms, missing context, and answers that end without a result.
Day 6: prepare the conversation around the interview
Technical strength is only part of the process. Prepare concise, truthful answers about:
- why you are exploring a change;
- why this role and company;
- preferred working model and location;
- work authorization and relocation;
- notice period or availability;
- compensation expectations, if you choose to discuss them;
- gaps, short tenures, career transitions, or title differences.
Never criticize a previous employer to make your move sound justified. Focus on what you learned and what you want next.
Prepare five questions you genuinely care about. Strong options include:
- What outcomes would make the first six months successful?
- Which problem is most urgent for the person joining?
- How are technical or product decisions made and revisited?
- What distinguishes people who do well on this team?
- What constraint is the team currently working hardest to improve?
Adapt questions to the interviewer. A recruiter can explain process and positioning; a manager can discuss priorities and expectations; a peer can describe daily collaboration and operational reality.
Also prepare a short closing summary: your interest, the strongest point of fit, and any important question still unanswered.
Day 7: reduce risk and recover
Do a light review, not a marathon.
Logistics
- Confirm the time zone and calendar link.
- Test camera, microphone, headphones, internet, and screen sharing.
- Install or update the required meeting and coding tools.
- Charge devices and prepare a backup connection.
- Choose a quiet, well-lit place.
- Keep the vacancy, CV, notes, and interviewer names accessible.
- For an on-site interview, confirm route, entry instructions, identification requirements, and arrival time.
Final content review
- Say your opening answer once.
- Review the requirement-to-evidence table.
- Read story headlines, not full scripts.
- Solve one easy warm-up problem if coding is expected.
- Stop studying early enough to sleep.
Memorizing complete scripts creates brittle answers. Remember structure, evidence, and key numbers instead.
During the interview
Listen to the entire question. Pause briefly. If the scope is unclear, ask. A concise clarification often demonstrates judgment.
For experience questions, establish context quickly and spend time on decisions and outcomes. For technical problems, externalize the reasoning that helps the interviewer follow you. When you do not know something, separate facts from assumptions:
I have not used that queue in production. My current assumption is that ordering is guaranteed within a partition, so I would verify that before choosing the key. Here is how I would evaluate it.
That answer is more credible than bluffing.
Treat hints as collaboration, not failure. Interviewers want to know whether you can incorporate new information. If you spot a mistake, correct it openly and continue.
After the interview
Within thirty minutes, write down:
- questions asked;
- answers that worked;
- unclear or weak moments;
- facts learned about the role;
- commitments or follow-ups;
- your updated level of interest.
Send a short thank-you message when appropriate. Reference one specific part of the conversation and provide any promised material. Do not send an essay or demand an immediate decision.
Update your application tracker with the next expected step and date. If the stated date passes, one concise follow-up is reasonable. Continue other applications rather than pausing your entire search for one process.
The seven-day checklist
- Day 1: vacancy decoded into outcomes, skills, scope, and constraints.
- Day 1: company and interviewer research completed.
- Day 2: six to eight honest STAR stories prepared.
- Day 3: high-priority technical foundations refreshed.
- Day 4: actual interview format practised.
- Day 5: mock interview completed and weak answers repeated.
- Day 6: motivation, logistics, and questions prepared.
- Day 7: technology tested, notes simplified, and recovery protected.
- Afterward: debrief, follow-up, and tracker updated.
Preparation cannot remove uncertainty, and it should not try to turn you into a different candidate. It makes your real experience easier to evaluate, your gaps easier to discuss honestly, and your decisions easier to trust.