Soham Parekh’s first day at Digger was Monday, June 30. He applied to our Founding Engineer role; his profile clearly stood out. Little did we know at the time what was hiding behind his resume! For those of you who don’t know - Soham turned out to be a serial “over-employed” practitioner. He worked at multiple companies simultaneously and used various tricks to keep this going for years. Here’s a good recap of what happened.

So Monday was also Soham’s last day with us - over the weekend background checks came through with alarming feedback, and we decided not to proceed with his onboarding. This was before the story blew up on X. We didn’t know the full scale of the issue yet, only that several founders I reached out to said the same thing - that Soham Parekh worked multiple jobs simultaneously and misled them about his location and visa status.

Was he really this good?

Yes, he was - or so we’d like to think. Realistically it is more likely we are not as good as we’d like to think (due to illusory superiority) but this illusion is also very helpful in startup land so I’d rather keep it going for a bit longer. It is somewhat comforting that other founders who employed Soham Parekh seem to all agree that he performed extremely well in their interviews.

The method we used and are still using to assess candidate’s technical skills in the interview is blend of practices we used to hire for Palantir and Amazon before starting Digger, adapted for early stage startup needs (speed is everything). We don’t use coding puzzles or abstract braintwisters - because these can be trained for. No take-home assignments or work trials either - the best people consider it waste of their time (rightfully so). Instead, we use something that can be loosely described as “freestyle system design”.

It’s an open-ended, under-defined business problem that needs a technical solution. It can be any kind of an existing software product with some known technical complexity; YC startup directory is a good inspiration. For example, let’s build Segment - a commercial product that allows users to collect usage analytics in their apps and integrate with other analytics tools (no frontend of its own). How would you build such a tool? What would be the main moving parts? How would you structure the backend(s)? Frontend(s)? What about infrastructure? What would be the tradeoffs between multiple possible approaches? What would be the biggest cost? What would be the most cost-effective setup? And what if money was no object and speed was all that mattered - would the design be any different? And so on.

There is no right or wrong solution. Most of the time something entirely new and unique ends up being designed. But the resulting solution matters very little if at all. The signal is in the way the candidate reasons about possible options as they work through the problem - particularly the speed of evaluating tradeoffs and discarding some approaches but not others and zooming in and out. It is possible to get lucky once or twice on a familiar problem; but because it’s a realtime conversation and there are so many ways to build each component it only takes a few questions to arrive at something that was likely never done before. From there it’s very clear whether the person knows what they are talking about or not. It’s just not possible to keep up with such a conversation without knowing all the building blocks inside out and having enough spare brain capacity left to not lose track of the business side and UX.

The very best treat it like a game. To them it feels like an easy chit chat with spare time for jokes. They’d juggle multiple complex (and correct) solutions simultaneously, digress into moonshot ideas that are crazy but kinda fun, and point out design flaws in present-day state-of-the-art tooling. It takes them seconds - not minutes - to put a complete solution into words, with precision. I’m yet to meet someone who can do such an exercise with ease and at the same time doesn’t possess the abilities of the proverbial 10x engineer. Interestingly, you don’t need many years of industry experience or knowledge of specific tools to get to this level - just insane capacity for learning coupled with insatiable curiosity.

Soham Parekh was clearly on that level while interviewing with us. He’s a brilliant engineer. Whether or not he would have chosen to exercise his ability afterwards is of course an entirely different matter. And then there’s track record, honesty and integrity; so we chose not to take a risk on him. But at the same time we genuinely wish him success. His appearance on TBPN suggests that he might have learned his lesson this time round. Bad track record can be fixed with good track record; that’s all that needs to be said, there’s no need to make judgement calls and predictions.

You want more Sohams, not less

It is tempting to change your recruitment process to de-risk from such situations. Perhaps add some sort of a pre-screening. Do more thorough background checks so that the next Soham Parekh doesn't pass your filter. But this is precisely the wrong thing to do. You actually want the opposite, and here’s why.

The very best in any field live life on their terms. If you want to attract top talent, you need to learn to see the world from their point of view. They always have options. They have no reason whatsoever to apply for jobs - because jobs apply to them. Unless, of course, there is some kind of a problem elsewhere in their life.

If you don’t have a strong employer brand where you can afford to select the best among the best from inbound, the only way to get to such people is your network. But if you have such a network already then you know it and don’t need this advice. The only other option is luck, but relying on luck is not a strategy. So you can’t afford to de-risk your pipeline completely. You will filter out the next Soham Parekh, but you will also filter out other people who do not yet have a stellar track record. You need to take chances on people who haven’t yet switched to “inbound mode” themselves.

Think of it this way: it is a much lower cost to have a few false positives (hire someone like Soham and later find out) than to never have one but at the cost of limiting your options to good-but-not-great people. Because that’s what de-risking with more stages and screenings would achieve - someone else would spot an outlier and move faster.

So, yes, if another Soham Parekh shows up we’d absolutely give him a chance. You should too. Just do background checks! And don’t ask for references, this can be gamed too. Much better to reach out cold to former employers (most will reply).

If you are not that Soham Parekh - come join us

We are building AI for infra and recently raised a seed round led by Initialized Capital and some top devtool angels - Olivier Pomel (founder of Datadog), David Cramer (founder of Sentry), Ben Porterfield (founder of Looker), Michael Grinich (founder of WorkOS) and many others. We’re opening an office in San Francisco.

Apply here: Founding Engineer - Open Source (SF, office)

It is obvious that the bulk of infrastructure work will be re-shaped by LLMs very soon - much more than any other discipline in software. We just need to figure out the right package for it. It is much harder with infra than with say frontends or backends, but it also has the biggest prize. The opportunity window is wide open to build the next cloud hyperscaler that is AI-first. Cursor is just the beginning. What happens when you’re done in Cursor? Your app works locally - then what? Is infra going to be the same in 5 years as we have it today? Clearly not. So come join us to build it.