The Engineer in the Half-Space

You are reading interview loop feedback. You are going through the notes and it looks like neither a no-go nor a go. You are divided in your head too. Mitch does not seem to score high in system design, algorithms, or anything obvious for that matter. The general consensus is that Mitch does not cut it. Your gut says interview him yourself. So you do. In the end, you call it a hire. Mitch starts the job. Everyone has some doubts. A few weeks pass and people like what Mitch is doing. He is going through onboarding, mapping the work , fixing runbooks, asking questions, documenting things that have not been documented. He also takes on projects and tries to help, even though he does not have the full context yet. He is present in meetings. Sometimes everyone likes a person because they are pleasant, agreeable and simply fun but they won’t add much. But sometimes the team is noticing something before it has the language for it. Mitch is a gap reader. The Interview Loop Misses This Person Most interview loops are better at measuring bounded skill. Give someone a system design problem, and you can score their architecture and trade-offs. Give them a leetcode problem, and you can score correctness, time and space complexity. The gap reader is harder. Mitch’s value is not that he knows every answer. He notices where the answer should be and why nobody can find it. He asks the question that exposes a missing owner. He notices that two teams are referring to the same thing differently. He can feel when a handoff is going to fail because everyone assumes they're aligned and no one has checked. He senses a dependency that won’t miraculously be delivered. That does not always look impressive in an interview. Sometimes it just looks like a person asking oddly practical questions. Credit for Nothing Happening The First Signal Was the Mess Mitch does not join and immediately redesign the platform . He fixes the onboarding doc , tries to understand the request path, which service calls which. Teams have fossil records of how things used to work, runbooks people stopped trusting, tribal knowledge hidden in old slack threads. Mitch takes his time to do some archeology. Most people work around that mess because they want to get to the real work. Mitch treats the mess as work . Mitch understands that if the first person gets stuck there, the next person will too. So he closes the loop. He asks the question, gets the answer, and puts it somewhere useful. He removes future drag. He Works in the Gaps Mitch lives in the half-spaces. He is between product and engineering , between design and rollout, between merged and safe in production , and between a blocked junior engineer and the team pretending standup will surprisingly reveal it. Mitch may not always be the loudest person in the system design discussion. Often he is listening , taking notes down, asking who’s the owner, what do we do if this fails , do we have a migration plan, what do we do with runbooks, who shou