The senior engineer who never asked a single question

I've conducted more than 500 technical interviews from the hiring side, and I've noticed how often capable engineers approach coding exercises as something they need to finish as quickly as possible.

I understand the pressure. There's a limited amount of time, someone is watching, and you want to demonstrate that you can write good code.

But speed doesn't tell me whether someone has understood the requirements.

In this case, storing an index wasn't inherently wrong. If the list never changed, it could have been perfectly reasonable.

But the exercise explicitly included sorting and filtering. Both operations change how items appear in the collection, and neither guarantees that a position will continue to represent the same item.

The code had made a product decision without anyone noticing.

I see similar assumptions in larger engineering problems.

In mobile applications, they appear in navigation state, authentication flows, background operations, and asynchronous updates. In backend systems, they appear in pagination, retries, and operations that might execute more than once.

You can have well-structured code that compiles, passes its existing tests, and still produces behaviour nobody intended.

Sometimes the problem isn't the implementation. It's the decision nobody realised had been made.

I wasn't counting how many questions the candidate asked. I wouldn't reject someone simply because they started coding without requesting clarification.

What interested me was how he responded once we examined the behaviour.

Could he explain why he'd chosen that approach? Did he understand what would break when the requirements changed? Could he reconsider the implementation without defending it simply because he'd already written it?

In this interview, he recognised the problem and understood the alternative. I didn't need to teach him about stable identifiers.

The technical knowledge was there.

What had been missing was the decision to clarify an important assumption before implementing it.

I also think interviewers have a responsibility here.

If I deliberately leave a requirement unspecified, I need to give the candidate a fair opportunity to clarify it or discuss the alternatives.

Otherwise, I'm evaluating whether someone guessed what I had in mind.

That's not how I want to assess a senior engineer.

I'm more interested in how someone reasons through ambiguity than whether their first implementation happens to match my expectations.

If you're preparing for a senior or staff engineering interview, I'd recommend spending one evening on something other than another algorithm problem.

Take a feature you've already shipped and look at the original requirements.

Find three decisions your implementation made that weren't explicitly specified.

Maybe changing a filter clears the current selection. Maybe signing out resets the navigation stack. Maybe a background upload continues after the user leaves the screen.

For each decision, write down why you chose that behaviour and what would need to change if the product required something different.

Then practise explaining it out loud.

During an interview, you need to explain your approach, identify trade-offs, and adjust when new information changes the problem. Knowing the implementation is only part of that conversation.

If you want to practise that part, Interview Runtime gives you real interview problems for iOS and Android, so you can rehearse the reasoning, not only the code.

Writing the code is one part of the job. Knowing which problem you're really solving is the other.