Technical Interviews in Tech: How to Prepare & Explain Your Thinking

Technical interviews in tech are where strong candidates fail most often - not because they can't code, but because they go silent for five minutes and then write a solution without explaining it. This guide covers the technical round only: the four common formats, a two-week prep plan, a full worked example of thinking out loud, and what to do when you get stuck.

If an HR round comes before or after the technical one, read our guide to HR interviews in tech too.

What types of technical interview are there?

Four main ones: live coding with an interviewer, a take-home assignment, system design, and a technical conversation about past work. Most companies combine two or three and tell you in advance which - ask if they don't.

• Live coding: 45 to 60 minutes in a shared editor or on a whiteboard. An algorithmic problem or a practical task - implement a function, fix a bug, build a small endpoint. Tested: reasoning, communication and clean code.
• Take-home: a small project of a few hours to a few days, followed by a discussion. Tested: structure, tests, a README, and how well you explain your decisions.
• System design: mostly for senior roles. "Design a URL shortener" - on a board, no code. Tested: clarifying questions, trade-offs, and thinking about scale.
• Past-work deep dive: "Walk me through the last system you built." Tested: depth, ownership, and whether you understand why things were built the way they were.

How do you prepare for a technical interview in two weeks?

Week one for foundations and problems, week two for practicing out loud and a mock interview. Ninety minutes to two hours a day is enough for most roles; senior candidates add three or four system-design sessions.

Week 1: foundations and problems

• Days 1-2: review the data structures that show up in almost every interview - array, string, hash map, set, stack, queue, tree, graph - and time and space complexity (Big O).
• Days 3-6: 10 to 15 problems of different kinds - two pointers, sliding window, tree traversal, BFS/DFS, sorting, hash maps. Variety beats volume: the goal is to recognize a problem type, not memorize solutions.
• Day 7: go back over the week's code and ask of each solution, "how would I explain this to someone else?"

Week 2: out loud and a mock interview

• Days 8-10: solve one problem a day out loud with a 40-minute timer, and record yourself. On playback you'll hear exactly where you went quiet.
• Days 11-12: a mock interview with a friend in the field, or with a simulation tool. Custro has an AI mock interview that gives feedback on your answers (part of the Pro plan).
• Days 13-14: pick two or three projects from your resume and prepare a two-minute explanation for each: the problem, what you built, and one decision you'd change today. Interviewers ask about what's on your resume, so make sure every line there is something you can defend - see how to write ATS-friendly resume bullets.

How do you think out loud in a technical interview?

Narrate each step before you take it: what you understood from the question, which approach you chose and why, its complexity, and how you'll test the code. The interviewer can't give credit for thinking they didn't hear.

A full example. The question: "Given an array of numbers and a target, return the indices of two numbers that add up to the target." Here is what a strong answer sounds like, step by step:

• Clarifying questions (one minute): "Is there always a solution? Can I use the same element twice? Can numbers be negative?" Each answer changes the solution, and asking shows how you think.
• Simple solution first (one minute): "The direct way is to check every pair - two loops, O(n²). It works, but it's slow for large inputs." Don't write it; say it.
• Improve it (two to three minutes): "If I store every number I've seen in a hash map with its index, then for each new number I only check whether its complement is already there. One pass, O(n) time and O(n) space."
• Write it while explaining: "I check for the complement before adding the current number, so I never use the same element twice."
• Test it: walk through a small example by hand, then the edge cases - an empty array, two equal numbers, negatives.

Notice that the code is the short part. Most of the credit in an interview like this comes from the clarifying questions, the path from the simple solution to the good one, and the testing at the end.

What should you do when you get stuck?

Say out loud where you're stuck and go back to a small example. Thinking in silence only stretches the pause, and an interviewer who knows where you are can give you a hint - taking one and using it is completely fine.

• Describe what you tried and why it fails: "Sorting gives me O(n log n), but I lose the original indices."
• Solve a 4-5 element example by hand on the board. The pattern often shows up once you see the steps.
• Ask yourself out loud: "Which data structure would answer the question I keep asking, fast?" Usually it's a hash map.
• If time is running out, finish the simple solution. A working O(n²) beats an unfinished O(n).

How do you approach take-homes and system design?

In a take-home, ship fewer features and more structure: a README, tests, and a short "what I'd do with more time" section. In system design, start with questions about scope and load, and only then start drawing.

• Take-home: respect the time limit you were given. A four-hour task submitted after three days of work raises questions, not scores.
• Take-home: write down your assumptions and trade-offs in the README. That's the basis of the conversation that follows.
• System design: ask how many users, how many requests per second, what must be fast and what can wait - before drawing a single box.
• System design: start with a simple version that works (one server, one database), then show where it breaks and what you'd add.

How do you walk through a past project?

In three layers: the business problem, the architecture at napkin level, and one decision you made yourself - including what you'd do differently today. Two minutes for the overview, then let the interviewer choose where to dig.

• The problem: who the users were and what hurt. "Support agents waited a minute for a customer's history to load" beats "we built a microservice".
• The architecture: three or four components and how they talk. Skip the name of every library.
• Your decision: "I chose a message queue over direct calls because..." - with the trade-off it brought.
• What you'd change: this shows more maturity than anything else in the conversation. A candidate who says everything was perfect sounds like someone who never looked back.

At the end, ask about the work itself: how deploys happen, what the hardest technical problem on the team is right now, and how code review works. Save questions about benefits for the HR conversation. If you're running a full search, fold this prep into a wider plan - our accelerated tech job search plan puts interviews inside two structured weeks.