Canonical Technical Interview (Preparation Checklist)
A strong technical interview plan starts with the job description, not a generic list of coding puzzles. Confirm the interview format and tools, map required skills to evidence, then practice role-relevant tasks aloud. Review your projects, prepare four behavior examples, and plan logistics. Afterward, note gaps and use them to guide your next steps.
Technical interviews can feel stressful when the format is unclear or your preparation covers skills the role will not test. A short, focused plan can make the work more manageable: you know what to practice, what evidence to bring, and what questions to ask. This checklist applies to software, data, IT, engineering, and other technical roles. The exact tasks vary by employer and level.
Technical interview formats, role expectations, and preparation overview
A technical interview may include coding, a work sample, system design, troubleshooting, a portfolio discussion, or questions about your past work. The job title alone does not tell you which format to expect. Use the job posting and recruiter’s guidance to shape your preparation, and treat unknowns as questions to clarify.
Stage 1: Diagnose the interview
Start by reviewing the job description. Mark each required skill and separate it from preferred skills. Then connect each requirement to evidence from a class, project, internship, or job. If you cannot name evidence, make that skill a priority for practice.
Ask the recruiter or hiring contact:
- What interview stages should I expect, and how long will each take?
- Will I be asked to code, design a system, review a portfolio, or complete a work sample?
- Which programming language or tools should I use?
- May I use documentation, an IDE, or other tools?
- Is the interview remote or in person, and what setup should I test?
Do not assume every employer uses the same process. For example, one software role may include a live coding task, while another may focus on debugging or design. A data analyst interview may test SQL and explain how you interpret results. Confirming the format helps you avoid spending most of your preparation time on the wrong task.
Checklist: Map the role to your evidence
| Job requirement | Evidence to prepare | Practice or review |
|---|---|---|
| Required programming language | A project, course task, or work example using it | Write and explain a small solution |
| Data structures or algorithms | Coursework or coding practice | Solve timed problems and test edge cases |
| SQL or data analysis | A report, query, or class project | Explain assumptions and check results |
| System or product design | A design decision you made | Discuss trade-offs, limits, and risks |
| Communication and teamwork | A project with shared responsibilities | Explain your role and how you handled feedback |
A degree is not a universal requirement for technical work. Follow the posting’s stated requirements, and be ready to show your skills through evidence. If a degree or credential is required, check the institution’s current accreditation through the U.S. Department of Education’s accreditation database or CHEA. Check program-level accreditation when it matters for the field or a license.
Next step: Write down the interview stages, required skills, and one piece of evidence for each skill.
Core skills, degree relevance, and evidence requirements
Interviewers may assess technical skill, problem solving, communication, and judgment. The balance depends on the role and seniority. A course title or credential can show what you studied, but examples help explain what you can do. Prepare to describe your choices, your contribution, and what you learned.
Prepare to solve and explain technical problems
For coding interviews, practice in the language named by the employer when possible. As you work, explain your reasoning in clear steps:
- Restate the problem and confirm inputs, outputs, and limits.
- Offer a simple approach before improving it.
- Name the data structures or tools you plan to use.
- Work through an example, including edge cases.
- Write the solution in small, readable steps.
- Test normal cases, boundary cases, and likely failure cases.
- Discuss time and space complexity if it fits the problem.
Complexity describes how an algorithm’s time or memory use changes as the input grows. For example, a solution that checks every pair in a list may take more time as the list grows than one that uses a set to check values. You do not need to force a complexity discussion into every task; explain it when it helps compare approaches.
Do not rely on memorized solutions. A familiar pattern can help, but the interviewer needs to see how you adapt it to the problem. If you get stuck, state what you know, ask a focused question, and test a smaller version. Clear reasoning gives the interviewer a way to understand your process.
Prepare for systems and role-specific questions
For roles that include design or operations, review the topics named in the posting. A systems question may ask you to sketch a service or explain how you would handle growth. Focus on the level expected for the role, rather than trying to present an advanced design for every scenario.
Be ready to discuss:
- Constraints: What limits the solution, such as cost, time, data, or user needs?
- Trade-offs: What does one approach improve, and what might it make harder?
- Reliability: How would the system respond to errors or service interruptions?
- Security: What data needs protection, and who should have access?
- Scale: What might change if usage or data volume grows?
For an IT support role, the relevant task may be diagnosing a user’s issue in a clear order. For a data role, it may involve checking whether a result is valid. Match your review to the work described, not to a generic “technical interview” syllabus.
Build project stories and behavior examples
Prepare two or three projects you can explain in detail. For each, note the problem, your role, the tools used, a key decision, the result, and one lesson. Be precise about what you did yourself. If the project was a team effort, distinguish your work from the group’s work.
Also prepare at least four concise examples using the STAR format: Situation, Task, Action, and Result. Choose examples that cover collaboration, ownership, conflict or feedback, and a setback or failure. A good response gives enough context to make the challenge clear, then spends most of its time on your actions and what followed.
Next step: Create a one-page evidence sheet with project details, technical choices, and four STAR outlines.
Practice plan, interview performance, and candidate experience
A useful practice plan moves from review to rehearsal. First refresh the skills in the posting, then complete tasks that resemble the interview, and finally practice explaining your choices aloud. Timed practice can help you manage the clock, but there is no universal score or number of problems that guarantees success.
Stages 2 and 3: Build evidence and rehearse
Use this sequence to prepare:
- Review core concepts: Choose topics named in the posting and note any weak areas.
- Complete role-relevant tasks: Practice coding, data questions, troubleshooting, or design as needed.
- Document projects: Prepare two or three examples, including decisions, results, and lessons.
- Run mock interviews: Ask a peer, mentor, or career adviser to play the interviewer. If that is not possible, record yourself explaining a solution.
- Request specific feedback: Ask whether your reasoning was clear, whether you tested the result, and whether your answer stayed on point.
- Repeat weak areas: Turn feedback into a short list of tasks for your next practice session.
Here are two practice scenarios, not reports of specific hiring outcomes:
| Scenario | What the interviewer may assess | Preparation checklist |
|---|---|---|
| A candidate is asked to write a function that handles a list with missing or repeated values | Clarifying questions, code quality, edge cases, and tests | Restate the task, explain the approach, and test empty and repeated inputs |
| A candidate is asked how to improve a service that sometimes fails | Diagnosis, reliability, and trade-off reasoning | Ask about symptoms and limits, identify likely causes, and explain how you would check them |
When practicing, do not treat speed as the only measure. Notice whether you explain assumptions, check your work, and respond well when a new constraint appears. Keep a short log of what went well, what caused trouble, and what you will practice next. That makes each rehearsal more useful than repeating the same task without review.
The day before and the day of the interview
The day before, confirm the time, location or video link, expected format, and any materials to bring. For a remote interview, test your connection, audio, camera, and permitted tools. For an in-person interview, check travel details and arrival instructions. Follow the employer’s rules on outside help and software.
During the interview:
- Listen to the full question before starting.
- Ask for clarification when a detail changes your answer.
- Share your reasoning without narrating every tiny action.
- Test your work, and say what you tested.
- If you make a mistake, correct it calmly and explain the change.
- Leave time for questions about the role and team.
Prepare a few questions that help you understand the work, such as what a typical project involves, how the team reviews technical decisions, or what success looks like in the first months. Choose questions that have not already been answered.
Next step: Use a checklist the day before, then focus on clear communication and careful testing during the interview.
Career pathways, hiring outcomes, and post-interview development
An interview is one stage in a hiring process, not a promise of a job or a verdict on your long-term potential. The same preparation can help you identify skill gaps and explain your background more clearly. After the interview, record what you learned and use it to guide the next application or learning step.
Stage 4: Follow up and improve
After the interview, send a brief thank-you note if appropriate. Mention a specific point from the conversation and restate your interest without making claims you cannot support. Then write down the questions you found difficult, the skills you used, and any feedback you received.
Turn that record into a targeted plan. If you struggled to explain a project, refine its summary and practice it aloud. If a coding task exposed a gap in testing, practice writing test cases. If a role required a tool you have not used, decide whether it appears in other roles you want before choosing a course or project to learn it.
A degree, bootcamp, or certificate can support a career move, but do not enroll based only on a promise of interviews or employment. Before paying, check total net cost, transferability, completion data, and independently reported outcomes. Confirm accreditation when relevant, and compare the program’s actual learning outcomes with the skills employers request. Employers differ, and no single credential or practice score guarantees a hiring result.
Next step: Keep a running interview log. Use it to spot patterns across roles, rather than treating one interview as a final measure of your ability.
Frequently asked questions
What should I study first for a technical interview?
Start with the job description and confirmed interview format. Prioritize skills listed as required, then practice the tasks most likely to test them.
How many coding problems should I solve before an interview?
There is no universal number that guarantees readiness. Focus on solving relevant problems, explaining your approach, testing edge cases, and learning from mistakes.
Should I use the programming language listed in the job description?
If the employer names a language or asks you to choose one, follow that guidance. Confirm permitted languages and tools with the recruiter when unclear.
What if I do not know the answer to a technical question?
Say what you do know, ask a focused question, and explain how you would investigate or test the issue. Avoid pretending to know something you do not.
How many behavioral examples should I prepare?
Prepare at least four concise STAR examples. Cover collaboration, ownership, conflict or feedback, and a setback or failure.
Do all technical jobs require a computer science degree?
No. Requirements vary by role and employer. Check the posting and prepare evidence of the skills it names, such as coursework, projects, work samples, or experience.
What questions should I ask the interviewer?
Ask about the work, team practices, technical decisions, or expectations for the role. Choose questions that help you assess the job and have not already been answered.
What should I do after a technical interview?
Send a brief follow-up when appropriate, then record strengths, gaps, and useful feedback. Use that record to plan focused practice for the next opportunity.
(This article was written by one of our staff writers, James Holloway. Visit our Meet the Team page.)
