Tech & Software Engineering Interview Questions

Tech interviews are unlike almost any other hiring process. You're being tested on two completely different things at the same time: your ability to actually write and reason about code, and your ability to communicate, collaborate, and handle the messier human side of software development. Both matter enormously, and the frustrating truth is that plenty of brilliant engineers get rejected because they can nail a LeetCode hard but can't explain their thinking clearly under pressure.

This guide is designed to help you prepare for both sides of that equation. Whether you're a junior developer going for your first proper role, a mid-level engineer eyeing a step up, or a senior looking to move into a more architectural position, the principles here apply. We'll cover behavioural questions, technical concepts by level, coding patterns, system design, and the questions you should be asking them. By the end, you'll have a clear picture of what to prepare and, crucially, how to present yourself well when it counts.

---

Why Communication Matters as Much as Code

Before we get into the specifics, it's worth understanding why so candidates fall short. Interviewers aren't just checking whether you can solve problems. They're trying to answer a much more practical question: "Would I want to work with this person every day?"

When you're silent during a coding exercise, heads-down and typing, the interviewer has no window into your thinking. They can't tell if you've understood the problem correctly, whether you're stuck or just concentrating, or whether you'd be someone who communicates proactively when things go wrong. That silence, even if you eventually produce a correct solution, can read as a red flag.

The fix is simple in theory, even if it takes practice: narrate your process. Say what you're considering, what you're ruling out, what trade-offs you're noticing. You don't need to perform or be theatrical about it. Just think out loud the way you would if you were pair programming with a colleague. That shift alone can meaningfully change how you're perceived.

---

Behavioural Questions for Tech Roles

Behavioural questions in tech interviews often get underestimated. Candidates spend weeks on LeetCode and then improvise their way through the "tell me about yourself" section. That's a mistake. These questions are your opportunity to demonstrate things code exercises simply can't show: your judgement, your communication style, how you handle conflict, and whether you take ownership.

Use the STAR framework (Situation, Task, Action, Result) as your structure, but don't make it feel robotic. The best answers feel like someone telling a story, not filling in a template.

1. Tell me about a complex technical problem you solved.

This is your showcase question. Choose something genuinely meaty, not something that sounds impressive but is vague. Include enough technical detail to show you know what you're talking about, but explain it in a way that a non-specialist could follow. The interviewers want to understand your decision-making process: how you broke the problem down, what options you considered, why you chose the approach you did.

A weak answer describes what happened. A strong answer explains your thinking throughout.

Example approach: "We had a performance issue in production where certain database queries were timing out under load. I started by pulling the slow query logs from our monitoring, identified a handful of queries that were running full table scans, and looked at the execution plans. The problem was that a key index had been dropped during a migration three weeks earlier and nobody had noticed because the load was lower then. I added the index back, tested on a staging environment, deployed during a low-traffic window, and put an alert in place so we'd catch similar issues faster. Response times dropped by about 70%."

That's specific, it shows process, and it ends with a measurable result.

2. How do you approach debugging a production issue?

This question is really asking: are you calm under pressure, and do you have a systematic method rather than just randomly poking things?

A solid answer sounds something like: "I start by trying to understand the impact. How many users are affected? Is it a complete outage or degraded performance? That shapes how urgently I need to move. Then I look at recent deployments and changes, because in my experience that's where the cause usually lives. I check logs and monitoring dashboards to narrow down where in the system things are going wrong, then I try to reproduce it in a non-production environment if possible. Once I've isolated the cause, I fix it, test it, and after deploying I keep an eye on the metrics to confirm it's resolved. I also write up a brief post-mortem so the team learns from it."

The post-mortem detail is worth including. It signals maturity and a team-first mindset.

3. Tell me about a time you disagreed with a technical decision.

What interviewers are listening for here is nuance. They don't want someone who always rolls over and agrees, but they also don't want someone who digs in and causes friction. The ideal answer shows you can make a clear, evidence-based case for your position, listen properly to the other side, and then commit fully once a decision is made, even if it wasn't yours.

A good framing: "I disagreed with the team's choice to build a new feature as a standalone microservice when I felt the complexity wasn't justified at our scale. I put together a short document outlining the operational overhead it would add and suggested we start with a modular monolith and extract later if needed. The team discussed it, and ultimately decided to go with the microservice approach because of longer-term plans I hadn't been fully aware of. Once I understood the reasoning, I was on board and I gave it my full effort. It actually worked out well, and I learned something about how to factor roadmap context into architectural decisions."

4. How do you handle tight deadlines?

The trap here is either sounding like you just heroically work longer hours, or being so cautious you sound like you'd never ship anything. The honest, mature answer is about prioritisation and communication.

"I try to scope very clearly at the start. If I can see early on that a deadline is at risk, I flag it straight away rather than hoping things will somehow come together. It's much easier for a manager or product owner to make decisions when they have time, rather than being surprised at the last minute. I'll break the work into must-haves and nice-to-haves, focus on what actually unblocks other people, and be honest about what's realistic."

5. Describe your code review process.

This question comes up more than people expect, and it reveals a lot about your engineering values. Think about what you actually look for: logic errors, edge cases, readability, test coverage, adherence to team conventions. Then think about how you give feedback. The best reviewers separate the code from the person, ask questions rather than making demands, and explain the why behind their suggestions.

---

Technical Concepts to Be Ready For

The specific questions you'll face depend heavily on the role, the stack, and the seniority level. Here's a breakdown of the concepts most commonly tested at each stage.

For Junior Developers

At junior level, interviewers aren't expecting you to have seen everything. They're testing fundamentals and, perhaps more importantly, your ability to explain concepts clearly and reason through problems you haven't memorised.

What's the difference between == and === in JavaScript? This is a classic because it catches people who've memorised syntax without understanding it. The double equals performs type coercion, so comparing a string and a number might still return true. The triple equals checks both value and type, so it's stricter and generally safer. Being able to give a concrete example, like 0 == "0" returning true while 0 === "0" returns false, shows you actually understand it rather than just reciting a definition.

Explain what a RESTful API is. REST stands for Representational State Transfer. A RESTful API uses standard HTTP methods (GET, POST, PUT, DELETE) to allow different systems to communicate. Each request is stateless, meaning the server doesn't retain information about previous requests. If you can briefly mention the idea of resources being represented by URLs and give a quick example, that's a strong answer.

What is version control and how do you use Git day-to-day? Interviewers want to hear that you use branches, write meaningful commit messages, understand how to handle merge conflicts, and know the difference between merging and rebasing at least at a conceptual level.

What's the difference between a stack and a queue? A stack is last-in, first-out (think a pile of plates). A queue is first-in, first-out (think a queue at a supermarket). Being able to name a real use case for each, such as call stacks for recursion and job queues for background tasks, lifts a basic answer considerably.

For Mid-Level Engineers

At this level, you're expected to have formed opinions about how to build things well, not just make things work.

Explain SOLID principles with examples. Don't just list the names. Pick two or three and give genuine examples from your own experience. The Single Responsibility Principle is the most commonly misunderstood in practice: a class doing "one thing" doesn't mean it has one method, it means it has one reason to change. If you can connect a principle to a mistake you've seen or made, that's memorable and credible.

How do you approach database optimisation? Talk about indexing strategy, query analysis (EXPLAIN plans), avoiding N+1 queries, caching where appropriate, and knowing when denormalisation makes sense. If you've dealt with a real performance issue, this is a great place to briefly reference it.

What's the difference between SQL and NoSQL? When would you use each? SQL databases are relational, with structured schemas and strong consistency guarantees. They're great for transactional data where relationships matter. NoSQL databases sacrifice some of that structure for flexibility and horizontal scalability. Document stores like MongoDB suit data with variable shapes; key-value stores like Redis are brilliant for caching. The honest answer is that the right choice depends on the use case, and being able to articulate that trade-off shows maturity.

How does authentication work (JWT, OAuth, sessions)? You should be able to explain the difference between session-based auth (where the server holds state) and token-based auth (where the client holds a signed token). Understanding the security implications of each, and when OAuth is the right choice for delegated access, is valuable at this level.

For Senior Engineers

Senior interviews are less about whether you know a concept and more about how you think through ambiguous, high-stakes problems.

How would you design a system to handle 1 million concurrent users? This is a system design question, and we cover those in more depth below. The key at senior level is demonstrating that you think about the full picture: load balancing, horizontal scaling, database read replicas, caching layers, CDNs, and where your bottlenecks are likely to be.

How do you approach technical debt in a legacy codebase? The mature answer acknowledges that not all technical debt is bad. Some was a deliberate trade-off that made sense at the time. The key is making debt visible, prioritising it pragmatically alongside feature work, and having a strategy for paying it down incrementally rather than attempting a risky big-bang rewrite.

Microservices vs monolith: how do you decide? This debate has swung back and forth in the industry, and experienced engineers know that microservices introduce significant operational complexity. A monolith is often the right starting point, with extraction into services happening when there's a clear team structure or scaling requirement that justifies it. Being able to reference Martin Fowler's "strangler fig" pattern shows you've engaged with this seriously.

How do you ensure code quality across a team? Talk about code review culture, automated testing, linting and static analysis, agreed coding standards, and psychological safety (people need to feel comfortable raising concerns without fear of blame).

---

Common Coding Patterns to Practise

If you have a technical screen involving algorithmic problems, the good news is that a relatively small set of patterns covers a large proportion of what comes up. You don't need to memorise hundreds of solutions. You need to recognise which pattern applies and be able to implement it.

Two-pointer technique is useful for problems involving sorted arrays or linked lists, such as finding pairs that sum to a target. The idea is to use two indices moving towards each other or in the same direction to avoid nested loops.

Sliding window is for problems involving subarrays or substrings, like finding the longest substring without repeating characters. You expand the window on one end and shrink it on the other.

BFS and DFS are your bread and butter for tree and graph problems. BFS is level-by-level using a queue; DFS goes deep using recursion or a stack. Know when to use each: BFS is great for shortest-path problems, DFS for exploring all possibilities.

Dynamic programming basics come up more than people expect. Start by recognising whether a problem has overlapping subproblems and optimal substructure. If so, think about whether you can work top-down with memoisation or bottom-up with tabulation.

Hash maps for O(1) lookups are the solution to a surprising number of problems. If you find yourself writing a nested loop, ask whether a hash map would let you reduce it to a single pass.

For practice resources, LeetCode is the industry standard. Start with Easy problems and move to Medium once you're comfortable. NeetCode.io is particularly good because it organises problems by pattern with excellent video explanations. HackerRank and Codewars are also solid options, especially if you prefer a slightly less competitive atmosphere.

---

System Design Questions

System design interviews are typically reserved for mid-level and above, though some companies include them for all engineers. The goal isn't to produce a perfect design. It's to demonstrate that you can reason through complexity, make sensible trade-offs, and communicate your thinking clearly.

Use this framework consistently:

Scope the problem first. Ask clarifying questions. How many users? What's the read/write ratio? Does it need to be globally distributed? Are there specific latency requirements? This step alone signals seniority.

Capacity estimates. You don't need to be precise, but showing you can do rough maths builds credibility. If a service has 10 million daily active users and each makes 5 requests per day, you're looking at roughly 580 requests per second on average, probably 3-4x that at peak.

High-level design. Sketch the major components: clients, load balancers, application servers, databases, caches, CDN. Don't go too deep yet. Get alignment on the overall shape.

Deep dive. Pick the most interesting or challenging component and go deeper. If it's a URL shortener, talk about how you'd generate short codes, handle redirects at scale, and store the mappings. If it's a notification system, talk about queue-based delivery, deduplication, retry logic, and handling different channels like email, push, and SMS.

Trade-offs. Always close by acknowledging what you've assumed and what the downsides of your approach are. There's no perfect design, and interviewers respect engineers who can articulate that clearly.

Practice designs: a URL shortener (great for starting out), a notification system, a ride-sharing backend, and a rate limiter. These come up frequently and each surfaces different interesting problems.

---

Questions to Ask Them

The questions you ask at the end of an interview tell the interviewer a lot about what you value. Avoid questions about salary or holiday entitlement at this stage (unless they've raised it). Focus on things that genuinely help you evaluate whether this is a good environment to grow in.

"What does the engineering culture look like here, particularly around things like code review and technical standards?" This shows you care about craft and collaboration.

"How does the team handle technical debt? Is there dedicated time for it, or does it get squeezed in around feature work?" This surfaces a lot about how the team actually operates versus how it describes itself.

"What does the deployment process look like? How often are you shipping to production?" This tells you about maturity of process and autonomy.

"How are architectural decisions made? Is it the tech lead, a group process, or something more informal?" Understanding the decision-making culture tells you a lot about whether you'd feel heard.

"What would I actually be working on in my first sprint?" This is practical, shows eagerness, and often generates a much more honest, specific conversation than the usual interview pleasantries.

---

Putting It All Together: Final Tips

Practise talking through your code out loud. If you've never done this before, it feels strange at first. Do a few sessions on your own, recording yourself, or use a platform like Pramp to practise with real people. The goal is to make narration feel natural rather than forced.

Clarify the problem before writing a single line. This isn't delaying tactics. It's what good engineers actually do. Restate the problem in your own words, confirm your understanding, ask about edge cases. Interviewers routinely build ambiguity into problems deliberately to see whether you'll catch it.

Start with a brute-force solution and optimise from there. Candidates freeze trying to think of the optimal solution before they've written anything. A working brute-force approach shows you can solve the problem. Then you can talk about how to improve it. That conversation is often more valuable to the interviewer than the optimal solution arrived at in silence.

Ask about scale and constraints. Even if the problem seems simple, asking "do I need to worry about scale here?" or "should I assume this needs to handle concurrent requests?" signals the kind of thinking that distinguishes senior engineers from junior ones.

Use RoleReady's Interview Prep tool to generate role-specific questions from the actual job description. Generic preparation will only get you so far. If you can practise with questions tailored to the specific stack, domain, and seniority level you're interviewing for, your preparation becomes dramatically more targeted and effective.

Tech interviews are hard, and the format doesn't always favour the best engineers. But the candidates who do best aren't necessarily the most technically brilliant. They're the ones who prepare thoroughly, communicate clearly, and show that they'd be a genuine asset to a team. That's entirely within your control.