Understand the assessment before choosing a syllabus
Technical interviews explore how you apply relevant knowledge and reason through practical work. A software candidate might write or debug code; a data candidate might analyse a dataset or discuss SQL; an IT support candidate might diagnose a user problem. By the end, you should have a focused preparation plan for a specific vacancy.
The subjects depend on the role, level, and assessment format. Do not assume every candidate needs advanced algorithms or system design. Ask the organiser about the format, duration, language or tools, permitted references, and any take-home task. Clarify rules for AI assistance rather than guessing.
Read the job description and classify likely topics as important now, useful later, or uncertain. Match each important topic to a skill you can demonstrate and a gap that needs practice. Where the description is vague, ask what kind of task or discussion to expect without requesting confidential interview questions.
Prioritise relevant fundamentals
Fundamentals are concepts that help you explain and troubleshoot a solution, even when the framework changes. Use the following software examples only where they match the vacancy. For other roles, replace them with relevant foundations such as data quality, networking, access control, or operating-system troubleshooting.
Complexity describes how resource use grows as inputs grow. Learn it when relevant to your assessment, rather than adding terminology you cannot explain. Likewise, system design expectations vary greatly with seniority: start with how your own application works and its limits.
| Area | What to practise | Evidence of understanding |
|---|---|---|
| Programming | Variables, functions, control flow, types, and error handling | Explain a small function and debug an incorrect result. |
| Data structures and algorithms | Relevant collections, searching, sorting, and simple complexity | Choose a structure and explain how time or memory use changes with input size. |
| APIs and databases | Requests, responses, validation, queries, and data relationships | Trace data through a feature and handle missing or failed responses. |
| Testing and debugging | Expected behaviour, edge cases, reproducible failures | Write checks and explain how you isolated a defect. |
| Version control | Commits, branches, reviews, and resolving conflicting changes | Describe how you kept a project understandable and coordinated changes. |
Use a structured problem-solving process
The interviewer needs to understand your reasoning as well as see a result. Practise speaking clearly without narrating every keystroke. If you become stuck, explain what you know, identify the uncertainty, and test a smaller case.
- Understand the problem: restate the goal, clarify input and output, and ask about constraints. Work through a small example.
- Explain an approach: describe a straightforward solution first and discuss alternatives where useful. Check assumptions before coding.
- Implement a solution: write understandable code or analysis in small steps. Use meaningful names and separate important responsibilities.
- Test it: check a normal case, empty or missing inputs, boundaries, and errors relevant to the task. Compare actual and expected results.
- Discuss trade-offs: explain time, memory, clarity, reliability, and unfinished work where appropriate. Suggest improvements without claiming they are already implemented.
Review projects, mock interviews, and take-home tasks
Reopen your own work and practise tracing an important feature end to end. Review why you chose the tools, how you tested, what failed, and what you would improve. A mock interview with a peer can reveal gaps in explanation that solo practice misses.
For a take-home task, confirm the scope, expected time, submission format, and rules about libraries, collaboration, and AI. Build the requested minimum first, include setup instructions and tests where appropriate, and document assumptions and limitations. Do not submit another person’s work as your own or expose confidential data. If the scope seems unclear or excessive, ask for clarification before committing time.
After practice, record one specific improvement. For example, repeat an exercise involving error handling if you could build the happy path but not explain failures. Repeating only familiar questions can hide the gaps you need to address.
A flexible seven-day preparation plan
This illustrative plan assumes an interview is approaching. Adapt the workload to your time, health, current knowledge, and employer guidance. Seven days does not guarantee readiness or replace longer-term learning.
| Day | Focus | A concrete output |
|---|---|---|
| 1 | Review the vacancy and assessment format | Prioritised topics and questions for the recruiter. |
| 2 | Refresh the highest-priority fundamentals | Short notes plus exercises completed without copying. |
| 3 | Practise representative problems | Working solutions with tests and explained reasoning. |
| 4 | Review a relevant project | A diagram, a two-minute explanation, and honest limitations. |
| 5 | Run a mock assessment | Feedback on technical gaps and communication. |
| 6 | Revisit weak areas and practical setup | Improved solutions and a tested interview environment. |
| 7 | Light review and rest | Brief notes, questions, and confirmed logistics. |
Technical preparation checklist and activity
Avoid memorising solutions, practising only speed, or hiding uncertainty. Do not study unrelated advanced topics simply because they appear in a generic interview list. Use this checklist with one actual vacancy and make a plan for any unchecked item.
- Choose three priorities from the vacancy and attempt a small exercise for each.
- Record what you could do independently and where you needed help.
- Use those gaps to adapt the seven-day plan, then review progress after the next practice session.
Copy technical preparation review
Technical interview preparation review: 0 of 7 complete Review [ ] To review: Confirmed the format and assessment rules [ ] To review: Selected role-relevant fundamentals [ ] To review: Practised explaining a problem-solving approach [ ] To review: Tested normal cases, boundaries, and errors [ ] To review: Reviewed a project and my own contribution [ ] To review: Completed a mock interview and recorded feedback [ ] To review: Checked equipment, tools, timing, and permitted references A record of preparation tasks, not proof of mastery or a prediction of interview results.
Further reading
Yale’s computer science guide is specifically about computing assessments; MDN supports web-development fundamentals. Choose different official learning resources if your target role has a different technical focus.