Tech Job Interview Tips: Coding, System Design, Behavioral

TL;DR — Most tech interviews run in stages: an online assessment or recruiter screen, a technical screen with live coding, then a loop of several interviews covering coding, system design (for mid-level and senior roles) and behavioral questions. Practice coding problems out loud in a plain editor, clarify the problem before you write anything, talk through your approach and its trade-offs, and test your own code before the interviewer asks. Prepare five to seven STAR stories with numbers in them, and come with questions about on-call, code review and what success looks like in the first few months.

A tech interview tests two things at once: whether you can solve the problem, and how you think while you solve it. Microsoft's careers site says technical interviews assess problem solving, design, coding and testing, along with your past experience and how you'd handle scenarios from the role. Interviewers want to see how you break a problem down, not just whether you reach the answer.

This guide covers the usual shape of a software or data interview process, how to practice coding problems and talk through them, system design basics, behavioral rounds, take-home assignments, the questions worth asking, and what to do afterward. It's written for software engineers first, but most of it applies to data, machine learning and other technical roles.

What a typical tech interview loop looks like

Every company runs its own process, and it changes with the level you're hiring in at, so ask the recruiter for the details. Most follow a similar arc.

Some concrete examples of how that plays out:

• Amazon's mid-level software engineer (SDE II) process starts with an online assessment: 90 minutes for two coding questions, 20 minutes of system design scenarios and an 8-minute work style survey. The loop is four 55-minute interviews covering technical and non-technical areas, and Amazon says it reports results within five business days.
• Microsoft describes its technical interview as a short 45-minute round in which you write and run code in a third-party tool.
• Northeastern University's career office warns that many candidates are eliminated at the online assessment, so treat it as seriously as any interview. It also suggests asking ahead which platform a phone or video screen will use, since coding may happen in a shared document or on a tool like CoderPad.

Before your first technical round, ask the recruiter four things: how many rounds there are and what each covers, which platform and language you can use, whether there's a system design round at your level, and what tools are allowed during the interview, such as an IDE, documentation or an AI assistant. Never use a tool the interviewer hasn't permitted. Our guide to the phone screen covers the recruiter call itself.

How to practice coding problems

Know the fundamentals cold. Microsoft's prep guidance is specific: know at least one, ideally two, sorting algorithms that run in n log n time, be able to explain time complexity in big O notation, and know when to use arrays, strings, lists, trees, hash maps and graphs, along with the pros and cons of each.

Practice in interview conditions. Amazon's SDE II guide recommends getting comfortable coding without an IDE and expects syntactically correct code, not pseudocode. Microsoft likewise asks for clean code in the language you're strongest in. So practice in a plain editor without autocomplete, on a timer, and run your solution only after you've traced it by hand.

Practice out loud. Solving a problem silently and explaining it while you solve it are different skills, and the interview tests the second. Northeastern suggests practicing explanations and recording yourself to catch where you're unclear. A friend playing interviewer, a study group, or a mock interview all work.

Study patterns, not answers. A memorized solution falls apart when the interviewer changes one constraint. After each problem, write down the pattern it used (two pointers, a hash map lookup, breadth-first search, a sliding window) and why it fit. When you miss one, come back a few days later and solve it again from scratch.

How to talk through a coding problem

Strong candidates follow roughly the same steps whatever the problem. A Microsoft recruiter, interviewed by the company, said strong candidates diagram the problem, ask questions before they write code, and check their work without being prompted.

1. Restate the problem and clarify it. Confirm the inputs and outputs, the edge cases and the constraints: can inputs be empty or negative, how large can they get, does speed or memory matter more? Northeastern lists these as the questions to settle before you code.
2. Work a small example by hand. It catches misunderstandings while they're cheap.
3. Propose an approach and its cost. Start with the straightforward solution, state its time and space complexity, then improve it. Discuss the trade-offs, and check with the interviewer before you start coding.
4. Code it while narrating. Use clear variable names and say what each block is for. A Microsoft recruiter put it simply: talk out loud through your thinking, so the interviewer can follow you and guide you.
5. Test your own code. Walk through your example, then the edge cases: empty input, one element, duplicates, very large values. Microsoft's guidance adds boundaries, error conditions and security implications.
6. Analyze and improve. Amazon's guide asks you to consider runtime complexity and how to improve it.

Here's what that sounds like on a classic warm-up problem: given an array of integers and a target, return the indices of the two numbers that add up to the target.

"Before I start: can the numbers be negative? Can there be duplicates? Is there always exactly one answer, and can I use the same element twice? … Okay. The simplest version checks every pair, which is O(n²) time. I can do better by walking the array once and storing each number's index in a hash map. For each number, I check whether target minus that number is already in the map. That's O(n) time and O(n) extra space. Does that trade-off work for you before I code it?"

After coding it, you'd trace [2, 7, 11, 15] with a target of 9, then check [3, 3] with a target of 6 to make sure you don't pair an element with itself.

When you're stuck, say what you know and what you're unsure of, make a reasonable assumption and keep moving, and treat the interviewer's hints as signals that your approach can improve. Northeastern advises saying honestly when you don't know something and then reasoning through it. A Microsoft talent acquisition manager went further: staying receptive to feedback can count for more than acing every question.

System design basics (for mid-level and senior roles)

A system design interview asks you to sketch the architecture of a real service, such as a URL shortener, a news feed or a chat app, within a single interview slot. Whether you get one depends on your level: Amazon's SDE II prep page promises at least one system design question, and Microsoft advises reviewing distributed systems concepts if you don't use them every day.

The open-source System Design Primer breaks the interview into four steps:

1. Outline use cases, constraints and assumptions. Who uses it, how many of them, how much reading versus writing. Don't skip this; it decides everything else.
2. Create a high-level design. The main components and how they connect.
3. Design the core components. Go deeper on the important parts: the data model, the API, storage.
4. Scale the design. Find the bottlenecks given your constraints and address them with load balancers, caching, database replication or sharding, and so on.

The concepts to be comfortable with include load balancing, caching strategies, SQL versus NoSQL databases, replication and sharding, the CAP theorem (during a network partition, a system must choose between consistency and availability), and quick back-of-the-envelope estimates of traffic and storage. Amazon lists practicality, accuracy, efficiency, reliability, optimization and scalability as its design objectives, and expects you to ask questions that complete and validate your design.

The primer's own summary is the best advice for the room: "Everything is a trade-off." Name the trade-off behind each choice, say what you'd do differently at ten times the scale, and let the interviewer steer you toward what they care about.

Behavioral rounds: use the STAR method

Engineers sometimes treat the behavioral round as a formality. Amazon's guide says a significant share of its interviews focuses on past experience, because past behavior is an indicator of future success, with each interviewer typically asking two or three behavioral questions. It recommends specific examples with metrics, told in STAR form: Situation, Task, Action, Result.

Questions you're likely to hear in a tech loop:

• Tell me about the hardest bug you've tracked down.
• Tell me about a time you disagreed with a teammate about a technical decision.
• Tell me about a time you missed a deadline, or a release went wrong.
• Tell me about a time you had to learn a new technology quickly.
• Tell me about a project you'd do differently now.

Build a bank of five to seven stories from work, internships, class projects or open-source contributions, each with a number in the result: latency cut, errors reduced, hours saved, users reached. Spend most of each answer on what you did, and be ready for the technical follow-up, such as why you chose that fix over the alternatives. Our STAR method guide has a worked software engineering example, and behavioral interview questions lists the common prompts by theme.

Take-home assignments

Some companies replace or supplement live coding with a take-home project. GitHub has described its own: the exercise is copied into a new repository, you work in your own editor with your usual tools and can look things up online, and you submit a pull request. The timer starts when you get access to the repository, so candidates with more free time aren't favored. Automated tests run against your submission, and an engineer grades it against a scorecard.

How to do well on one:

• Read the instructions twice and note the time limit and what's being graded.
• Solve the stated problem, not a bigger one. Clean, working, tested code beats ambitious unfinished code.
• Write tests, even a few, and make sure they pass.
• Add a short README covering how to run it, the assumptions you made, the trade-offs you chose, and what you'd do with more time.
• Expect to discuss it. If there's a follow-up conversation, expect questions about why you built it the way you did, and be ready to defend each choice.

Questions to ask your interviewers

Interviews run both ways. Microsoft's Kenji Yamaguchi advises asking about what matters to you and your career goals, so you can confirm the role is a fit. Good questions for a technical team:

• What does on-call look like for this team, and how often would I be on it?
• How does code get from a pull request to production?
• How does code review work here, and how long does a typical review take?
• What would you want me to have shipped or learned by the end of my first three months?
• What's the biggest technical challenge, or piece of tech debt, the team is facing right now?
• How are levels and promotions decided for engineers?

For more, see our full list of questions to ask the interviewer.

After the interview

• Write down what you were asked while it's fresh, including the problems you struggled with. It's the best practice material you'll get.
• Send a short thank-you within 24 hours to your recruiter or interviewers, with one specific detail from the conversation. Our thank-you email guide has templates.
• Ask about timing, then wait it out. Ask the recruiter at the end of the loop when you'll hear back. If that date passes, a brief, polite follow-up to the recruiter is fine.
• If you get an offer, compare it on total compensation, not base salary alone; see how to evaluate a job offer.

Role-specific questions

The loop's shape is similar across technical roles, but the questions aren't. Our role guides cover what each interview actually asks, with sample answers:

• Software engineer interview questions
• Data engineer interview questions
• Machine learning engineer interview questions
• Product manager interview questions

Then rehearse out loud. Olive's interview practice runs a voice mock interview built from a real job description or any role you name, so the first time you explain your approach isn't in the real interview.

Sources

• Microsoft Careers — Technical interviewing
• Microsoft — How to ace a technical interview at Microsoft
• Amazon Jobs — SDE II Interview Prep
• Northeastern University Career Design — Interview Type: Technical
• GitHub Blog — How GitHub does take-home technical interviews
• Donne Martin — The System Design Primer