You cleared the English round. Good — that’s the filter that catches most people. Now you’re staring down the technical screening, and honestly, this is the round where “I’m a good developer” stops meaning anything by itself. Nobody’s grading your vibe here.
They’re grading whether you actually know the stack you claimed on your resume, at a depth you can only fake for about ninety seconds before it shows.
I’m going to be blunt in a way most guides won’t: if your answer to any of these sample questions makes you wince a little reading it, that’s useful information. Don’t rationalize it.
A wrong answer is wrong, even if you can explain your way around it—screeners have heard every version of that explanation before.
Read Also: Toptal Interview Questions By Stage: What’s Actually Asked at Each Round
JavaScript / Frontend Stack
Question: “Walk me through what happens when you call setState React—is it synchronous?”
Weak answer: “Yes, it updates the state right away and re-renders the component.”
That’s just wrong, and a screener catches it in about two seconds—(and its hook’s equivalent setter) is batched inside event handlers in most cases, which is exactly why you can’t reliably read the updated value on the very next line.
Strong answer: “It’s not guaranteed synchronous—React batches state updates inside event handlers for performance, so if I need the updated value immediately, I either use the functional update form or handle the side effect in a way that depends on the new state.”
The strong answer doesn’t just get the fact right; it shows the candidate actually ran into the problem before, which is the whole point of asking it.
Question: “How would you debug a memory leak in a long-running single-page app?”
A weak answer stays abstract—”I’d check the console for errors” tells a screener nothing.
A strong answer names actual tools (Chrome DevTools’ heap snapshot comparison and watching detached DOM nodes) and actual causes (uncleaned event listeners, stale closures in useEffect holding references, and timers that never get cleared). Specificity is the entire signal here.
Python / Backend Stack
Question: “What’s the difference between a list and a generator in Python, and when would you actually choose one over the other?”
Weak answer: “A generator is more memory efficient.”
Technically not wrong, but it’s a textbook definition with zero evidence you’ve ever had to make that choice under real constraints.
Strong answer: “A generator only computes values as you iterate, so I’d reach for one when I’m processing something large I don’t need to hold in memory all at once—streaming a big file line by line, for instance. If I need to iterate the same data multiple times or need random access, a list is the right call even though it costs more memory upfront.”
Question: “How do you handle a race condition in a Flask or Django app hitting the same database row?”
Weak answers wave at “using locks” without specifics. Strong ones talk about actual mechanisms—database-level row locking (SELECT ... FOR UPDATE), optimistic locking with a version column, or application-level queuing—and explain the tradeoff between them, since “just add a lock” is the kind of answer that gets a very pointed follow-up question.
Read Also: Toptal English Test: What It Actually Tests (And How to Pass It)
Mobile (Swift / Kotlin) Stack
Question: “What causes a retain cycle in Swift, and how do you fix one?”
Weak answer: “You use weak references.” True, but incomplete, and it tells the screener you memorized the fix without necessarily understanding the mechanism.
Strong answer: “It happens when two objects hold strong references to each other—most commonly a closure capturing self strongly while self also holding the closure. I’d mark the capture as weak self or unowned self depending on whether self could legitimately be nil at the time the closure runs.”
That last clause—knowing when to use weak versus unowned — is exactly the kind of detail that separates someone who’s actually shipped Swift code from someone reciting a Stack Overflow answer.
Question: “How would you handle a network call that needs to survive the app being backgrounded?”
A strong Kotlin/Android answer references WorkManager for deferrable, guaranteed background work; a strong Swift answer references background URLSession configurations or background tasks with proper expiration handling.
If the answer stays at “I’d just make the API call,” that’s a candidate who hasn’t dealt with a real app lifecycle yet.
Data / ML Stack
Question: “Your model has 99% accuracy on a fraud detection dataset. Is that good?”
This is a trap question, and it’s asked specifically because so many candidates answer “yes” immediately.
Weak answer: “Yes, 99% accuracy is excellent.”
Strong answer: “Not necessarily—if fraud only occurs in 1% of transactions, a model that predicts ‘not fraud’ every single time also hits 99% accuracy while being completely useless. I’d want to know the class balance first, and I’d be looking at precision, recall, and probably the F1 score or a confusion matrix instead of accuracy alone.”
This question isn’t really about ML theory—it’s testing whether you reach for the right evaluation metric instead of the first flattering number, which is exactly the instinct a client is paying for.
Read Also: Toptal Test Project: What Actually Gets You Rejected
The Pattern Across Every Stack
Notice what every strong answer above actually has in common: specificity, a real tradeoff acknowledged, and evidence of having hit the problem before rather than just knowing the definition.
The weak answers aren’t necessarily false — a lot of them are technically half-true — but they’re shallow in a way that reads instantly to someone who’s screened hundreds of candidates in that exact stack.
If you catch yourself giving a “textbook” version of an answer during practice, stop and ask what actually breaks in real production code, because that’s what’s coming next as a follow-up.
Prepping Without Just Memorizing These
Don’t memorize the sample answers above word for word—pick two or three recent, real situations from your own work where you hit something similar, and practice explaining those out loud. A specific real story beats a well-recited theoretical answer every time, because screeners can tell the difference within about one follow-up question.
And if you’re in the waiting period between this round and the next—or rebuilding after a rejection anywhere in the process—it’s worth having a second income lane running so the whole thing doesn’t feel like all-or-nothing.
The Fiverr MasterClass is genuinely a solid, structured way to build that parallel track while you’re deep in the Toptal process.
Disclosure: This post contains affiliate links. HustleSpire may earn a commission when you purchase through it at no extra cost to you.
The technical screening isn’t testing whether you know your stack exists—it’s testing whether you’ve actually lived inside it long enough to know where it breaks. Get specific, admit the tradeoffs, and stop reaching for the safe, textbook-sounding answer the second a question gets uncomfortable. That discomfort is usually the exact spot worth sitting in a little longer.
