The interview styles top companies use for technical screens

A payments company and a design tool will both tell you they run a standard technical interview. They will then ask completely different questions, score completely different things, and reject completely different people.

That is because a company's interview is downstream of what the company is scared of. A firm that moves money is scared of correctness and blast radius. A firm shipping a highly interactive product is scared of hiring someone who cannot make a browser feel fast. Both fears end up encoded in the questions, and you can usually work out which one you are facing before you sit down.

1. The backend deep dive

The most common senior screen outside of big-tech algorithm loops. One or two interviewers go deep on a server-side stack: how requests are handled, how data is stored and queried, what happens under load, what happens when a dependency is down.

It is testing whether you have operated something, not just built it. The tell is that questions keep moving toward failure. You will be asked what happens when the database is slow, when the queue backs up, when the same request arrives twice. Prepare by being able to describe a system you actually ran, including the parts that went wrong. See the backend deep-dive style for the shape of one.

2. The full-stack product screen

Common at product companies and almost universal at startups. Breadth over depth: some frontend, some backend, some data, some API design, usually anchored on a feature you would plausibly build there.

What it is really testing is whether you can own a feature end to end without needing three other people. The failure mode is a candidate who is excellent on one side and visibly uncomfortable on the other. You do not need to be equally strong everywhere, but you do need to be unembarrassed everywhere, and to know where your edges are.

3. The frontend depth screen

Deceptively hard, and frequently underestimated by backend-leaning candidates who assume frontend means CSS. A good frontend interview goes into rendering, state, the network, accessibility, and why a page feels slow even though every request is fast.

The distinguishing question is usually about performance or about state that got out of hand. If you can explain what actually causes a re-render, or what the browser is doing between a click and a pixel changing, you are already past most candidates. Frontend depth is the style to practise for this.

4. The distributed and real-time screen

Any company whose product is a stream of events rather than a set of pages: chat, collaboration, trading, logistics, anything with a live feed. Expect delivery guarantees, ordering, backpressure, reconnection, and what happens when a consumer falls behind.

This one has a very sharp signal. Candidates who have only read about queues talk about them as if messages simply arrive. Candidates who have run them immediately start talking about duplicates, ordering and the day the consumer lag alert went off. Idempotency is the single highest-value concept to have ready.

5. The architecture and trade-offs conversation

Usually senior and above, often with a staff engineer or an engineering manager. There may be no code at all. You are asked how you would build something, and then repeatedly asked why not the other way.

The trap is treating disagreement as an attack. When the interviewer pushes back, they are usually testing whether your position was reasoned or borrowed. Defend it with the reason you chose it, and concede cleanly when the counter-argument is better. Both moves score. Digging in on a bad position scores worst of all.

6. The security-flavoured screen

Standard anywhere handling money, health data or identity, and increasingly common everywhere else. It is rarely a pure security interview. It is a normal technical conversation where the follow-ups keep asking who could abuse this.

You are not expected to be a penetration tester. You are expected to have a threat model instinct: to notice that user input reaches a query, that a token has no expiry, that an endpoint trusts a client-supplied id. See the security-focused style.

7. The AI engineering screen

New, growing fast, and currently the least standardised of the lot. Expect questions about retrieval, evaluation, cost and latency, handling non-deterministic output, and what happens when untrusted text reaches a system that acts on it.

Because the field is young, interviewers weight engineering judgement heavily over tool familiarity. Someone who can explain how they would know their system got worse after a change is worth more than someone who can name six frameworks.

8. The algorithm loop

The classic big-tech format: timed data structure and algorithm problems, often two or three rounds of them. It is the most written-about interview style in existence and also the least representative of daily work, which is exactly why so many strong engineers underperform in it.

There is no clever way around this one. It rewards deliberate practice on the specific format, and that practice does not transfer much to the other seven styles. The important decision is whether the companies you are targeting actually run this loop, because a month spent on it is a month not spent on depth.

How to find out which one you are facing

1. Ask the recruiter what the round covers, how long it is, and who runs it. They answer honestly almost every time, and hardly anyone asks.
2. Read the job description for what it is scared of. Heavy emphasis on scale, uptime or compliance tells you where the follow-ups will go.
3. Look at what the company sells. The product is the best predictor of the interview.
4. Check the engineering blog and the careers page. Companies that have thought hard about interviewing tend to publish it.
5. Ask anyone you know who has interviewed there in the last year. Older than that and the process has probably changed.

Then prepare for that style specifically. Preparing for a real-time screen when you are about to sit a frontend one is not slightly wrong, it is entirely wasted.