Why this matters more than the right answer
The problem isn't set to check whether you know the solution. It's set to see how you think — because at work you'll meet problems nobody knows the solution to.
Hence a non-obvious consequence: someone who reasoned aloud and didn't finish often scores higher than someone who silently produced the correct answer.
A six-step template
1. Restate the problem in your own words. "So: given a list of numbers, find two that sum to a given value?" That catches misunderstandings immediately and buys you a few seconds.
2. Ask one or two questions. Can the list be empty? Integers only? Can values repeat? A clarifying question is the mark of someone experienced.
3. Name the simple solution. Even a poor one. "Brute force would check every pair — slow, but definitely correct." Now you have a solution and nothing to panic about.
4. Offer an improvement. "One pass would do it if I keep what I've seen in a dictionary."
5. Write and narrate. Not silently. "Walking the list, for each number I check whether its complement has appeared."
6. Test with examples. Empty list, single element, no answer exists. Almost everyone skips this step.
What to say when you don't know
Honestly: "I haven't met this before. Let me think aloud — it looks like a search problem, I'll start from there."
That's a perfectly good working answer. The interviewer wants to see how you approach the unfamiliar; it's how they work too.
Bad: silence, stalling, pretending to think while actually panicking.
When your mind goes blank
It happens to everyone, and usually from nerves rather than ignorance.
Say so. "I've lost my thread, give me a moment." An ordinary human remark that removes half the tension.
Go back to the problem statement. Read it aloud. Often that's enough for a thought to catch.
Start with the dumbest solution. Brute force. The moment something appears on the board, the panic subsides.
How to practise
Solve problems out loud at home. Not in your head — aloud, narrating every step. It feels awkward and silly at first; within a week it's habit.
Better still, with someone listening and asking questions. Which is an incidental benefit of team work: there you explain your decisions to others every day, so the skill is already in place by interview time.
People who've worked in a team are usually noticeably calmer in technical interviews. Not because they know more, but because they're used to thinking aloud with witnesses.
Открытые роли по теме статьи
Читать полезно, а делать — ещё полезнее. В эти команды можно написать прямо сейчас:
- iOS-разработчик — MAIBO - MedTech-пилот для клиник
- Контент-маркетолог / комьюнити — CohortX — платформа командных пет-проектовмаркетингtelegramseoконтент
Похожие статьи
- Rejections: how to respond and what to take from themWhy a rejection is usually not about you, how to ask for a reason and get an answer, and how not to burn out over months of searching.
- Отказы: как реагировать и что из них извлекатьПочему отказ чаще не про вас, как спросить причину и получить ответ, и как не сгореть за месяцы поиска.
- Fifteen SQL queries you'll be asked at an interviewStandard problems with notes on what each one tests, and the places beginners get them wrong.