The first technical at Wix, Monday, Wiz, Riskified, JFrog, AppsFlyer — they all run roughly the same 90-minute format. After enough conversations with engineers who've sat on both sides of the table, the structure is predictable enough that you can prepare for the slot, not just the questions.

Here's what actually happens, minute by minute, and what the interviewer is grading you on at each phase.

The 90-minute shape

Almost every first technical breaks into three blocks:

0–15 minutes — warm-up, introductions, motivation
15–60 minutes — coding problem
60–90 minutes — system design or technical depth dive

The blocks aren't strict. A coding problem that's going well sometimes runs to 70 minutes and the design block gets compressed. A coding problem going badly gets cut short and the interviewer pivots to "tell me about a project you're proud of" to salvage signal. But the shape is real, and treating each phase as its own preparation target is the right move.

0–15 minutes — the warm-up is not chitchat

This is the phase candidates underestimate most. The interviewer is checking three things:

Can you communicate in English at a level that works with a remote teammate in San Francisco or Berlin?
Are you the kind of person an engineering team wants to sit next to?
Do you have a real, specific reason to want this role — or are you spraying applications?

The two most common openers:

"Walk me through your last project at scale."
"What attracted you to this role specifically?"

Generic answers tank you here. "I want to work at Wix because Wix is a great company" is a fail. The interviewer is looking for evidence you read the job spec, looked at the team's tech stack, maybe pulled up a recent engineering blog post. If the role is a backend position on the payments team and you say "I noticed you migrated from Python to Go last year and I've been working on a similar migration" — that's a hire signal in the first 90 seconds.

For the project walkthrough, structure it: what was the problem, what was your specific role (not the team's role — yours), what tradeoffs did you make, what would you do differently. Three minutes, max. If you ramble for eight minutes, you've already used a third of the warm-up and the interviewer is now worried about your communication. Most of the same instincts that make a strong CV apply here — specifics over adjectives, ownership over team-we, numbers when you have them.

15–60 minutes — the coding problem

Israeli companies don't tend to use trick problems. The pattern is medium-to-hard LeetCode flavor with a real-world wrapper. Things you'll see often:

Graph traversal — shortest path, topological sort, cycle detection
Sliding window over a stream
Two pointers, especially on sorted arrays
Hashmap optimization to drop a nested loop from O(n²) to O(n)
Heap-based "top K" problems, frequently with a time window

A representative prompt: "Given a stream of events, each with a timestamp and a type, return the top-K most frequent event types within the last 5 minutes, updated as events arrive." That's a sliding window plus a heap plus some thought about how to evict expired counts. It's not exotic — it's the kind of thing that shows up in real telemetry pipelines.

One thing worth flagging: even when both you and the interviewer speak Hebrew, the coding problem is increasingly being conducted in English. The reason is simple — your future pair-programming partner might be in Austin. They want to see you can articulate "I'm thinking we use a min-heap of size K and pop the smallest when we see a more frequent element" without switching languages mid-sentence.

What they're actually scoring

This is where most candidates misread the rubric. The interviewer's score sheet is roughly:

Communication during problem-solving — are you thinking out loud, or staring at the screen in silence
Clarifying questions — did you ask about input size, edge cases, expected throughput before coding
Tradeoff articulation — can you say "this brute-force is O(n²) but trivial to write, do you want me to optimize first or get something working"
Code that compiles and handles edge cases — empty input, single element, duplicates
Optimal time complexity — yes, but it's #5, not #1

I've seen candidates write the optimal solution in silence and get rejected because the interviewer had no signal on how they think. I've seen candidates write a suboptimal solution while narrating clearly, asking good questions, and catching their own bug — and get hired. The performance is the signal, not just the artifact.

If you want to drill the talking-while-coding muscle, the interview simulator runs you through realistic prompts and grades you on exactly this dimension — communication, clarification, tradeoffs — not just the final code.

60–90 minutes — system design or technical depth

This block splits into two flavors. For mid-level and senior backend roles, you'll get a system design prompt. For frontend, mobile, or earlier-career roles, you'll often get a depth dive into something already on your CV — "you mentioned you built the caching layer at your last job, walk me through the design and what would change if traffic 10x'd."

Either way, the four-step structure is the same:

Clarify scope — read volume, write volume, latency targets, consistency requirements, geographic distribution. Don't skip this. Designing a URL shortener for 1M URLs total is a different system than 100M URLs per day.
High-level sketch — boxes and arrows. Client, load balancer, app servers, database, cache. Two minutes, no detail yet.
Component-by-component depth — pick the interesting components and go deep. For the URL shortener: how do you generate short codes (counter? hash? base62?), how do you store them (relational? key-value?), how do you cache hot URLs.
Tradeoffs — every choice you made, the alternative, and why. "I picked a base62 hash over an auto-increment counter because counters leak business metrics and require coordination across regions."

A canonical senior backend prompt: "Design a URL shortener handling 100M URLs created per day, 100K reads per second, with sub-50ms p99 latency globally." Don't try to design the whole thing in 30 minutes — pick the two or three components the interviewer signals interest in, and go deep there.

The Israeli-specific thing — directness

This catches non-locals off guard. Israeli interviewers will push back hard, even when you're right. "Are you sure?" "Wouldn't that break under concurrent writes?" "I don't think that's right." It's not personal. It's a pressure test.

The correct responses are: defend your reasoning if you still believe it, or change your mind if they've given you a real reason to. Both are fine. What gets you rejected is flailing — abandoning a correct solution because the interviewer raised an eyebrow, or refusing to update when they've made a good point.

If they say "are you sure that handles duplicates" and you walk through your logic and confirm yes, it does, here's why — that's a hire signal. If you immediately tear up your code and start over, that reads as "doesn't have conviction, will fold under code review pressure."

After the interview

Feedback comes fast in Israeli tech. 24 to 72 hours is the norm. If you've gone five business days without hearing back, the answer is no. Israeli recruiters don't ghost on the accept — they'll move you to the next round quickly because they're worried you'll get a competing offer. They sometimes ghost on the reject, especially if it was a clear no. Don't take it as ambiguity; treat silence past five days as a closed door and keep your pipeline moving. The current state of the hiring market makes pipeline width matter more than ever.

What to actually prepare

If you have four to six weeks before your first interviews:

30–50 medium LeetCode problems — focus on the patterns above, not random hard problems. Quality of pattern coverage beats quantity.
5 system designs walked through end to end — URL shortener, rate limiter, news feed, chat system, distributed cache. Practice saying them out loud, not just sketching them.
3–4 stories about your actual work — three minutes each, structured (problem, your role, tradeoffs, outcome). Rehearse them until they feel natural, not memorized.
One mock interview per week — with a friend, a paid service, or a simulator. The talking-while-thinking muscle atrophies fast if you only practice silently.

The 90-minute format is predictable enough that walking in unprepared is a choice, not a fate. Prepare for the slot, not just the question.