Your interview went well. You still got rejected.

I've conducted more than 500 technical interviews. One part of the process candidates rarely see is what happens after they leave.

The interviewers compare their notes and decide whether there's enough evidence to recommend moving forward.

You can answer every initial question correctly, have a good conversation, and still leave the interviewer uncertain about your ability to handle the work.

Here's an example.

When the question changes

Imagine you're interviewing for a Senior iOS or Android role.

You're asked to design a background document upload feature.

You explain the API, local state, concurrency and error handling. Your initial design makes sense.

Then the interviewer changes one condition:

The server saves the document, but the app loses the response. The user retries. What happens?

Your original design may work perfectly when everything goes as planned.

Now you have to explain what happens when the client doesn't know whether an operation succeeded.

How does the client identify the original upload?

How does the server recognize a retry?

What happens if the app process dies before the result is recorded locally?

Swift or Kotlin syntax won't answer these. They test how the system behaves when something goes wrong.

And your answers give the interviewer evidence of how you approach problems beyond the initial requirements.

Try this before your next interview

Take one technical problem you've already solved.

Spend five minutes explaining your solution out loud.

Then change one condition.

For a document upload feature:

Lost response. The server commits the upload, but the response never arrives. How do you prevent duplicate effects? Process death. The OS terminates the app. What information needs to survive so the operation can be recovered safely? Two devices. Both attempt the same logical upload. How does the system recognize that it is one operation?

Answer without checking your notes.

If the new condition breaks your solution, explain which assumption changed and what you would do differently.

You should be able to defend your decisions, recognize their limits and adapt when the requirements change.

That's valuable evidence in a Senior interview.

What you can control

A rejection doesn't automatically mean you failed technically.

Another candidate may have been a closer match. The team may have needed different experience. You may never receive enough feedback to know.

But you can prepare for the part of an interview where the first correct answer is no longer sufficient.

Practice the follow-up

I built Interview Runtime to help iOS and Android engineers practice this.

You answer a technical question. A constraint changes. You explain whether your original solution still works and what you would change.

You can practice for iOS, Android, or both.

$59 per platform, or $89 for iOS and Android together until October 31.

Practice with Interview Runtime

$59 per platform, or $89 for iOS and Android together until 31 October.

Practice with Interview Runtime