We fired an engineer.
And it all could have been avoided if I’d listened to my gut.
We live in a data-driven world – sometimes to a fault.
Especially for entrepreneurs who don’t get enough sleep and go into overdrive analyzing every decision.
As a result, it’s easy to fall into the trap of relying purely on data and ignoring intuition.
After all, a gut feeling doesn’t exactly stand up in court. And if everything else seems fine, it’s hard to trust a feeling.
But all too often, the gut is smarter than the brain.
And failing to listen to your intuitions can cause serious problems for your company.
What’s the Deal with Mike?
Two years ago, we were in a bind.
We had multiple projects going and we were strapped for resources. We had just landed a major client and risked losing them if we didn’t deliver.
With few options, we had to outsource.
We interviewed a guy from Long Beach – we’ll call him Mike – for a temporary support role.
From the start, he gave off a weird vibe. It was hard to describe. But by all other standards, he fit the job.
He worked as a programmer at Cisco for over 5 years.
All three of his references spoke highly of his work.
His interview with our Chief Data Scientist from Germany went perfectly. So did his interview with our CFO, David, and me – although he still gave off a weird vibe that I couldn’t put my finger on.
But a vibe is a vibe, and if his work is good, that’s that. Engineers aren’t always the most sociable people.
Sufficiently convinced, we onboarded him and put him on the project ASAP.
But it only got stranger from there.
Within his first week on the job, the whole team noticed something off.
Mike seemed… shady. He acted suspect, and he insisted on working remotely.
That’s not unusual. Everyone wants to work remote. There’s nothing inherently wrong with it. So, we approved the request.
Rtill, the team was suspicious. Everyone was watching him closely.
Then we saw the first clue.
One of the his Trello cards was signed with the username of a Chinese pop star.
When asked about it, Mike brushed it off. “It’s for a different project, I was on a different account…”
Ok, maybe it was an honest mistake. He’s not on an exclusive contract.
But still. Weird.
The Final Straw
At this point, everyone on the team was watching him like a hawk. We all had the feeling that Mike’s weird vibe was more than just a vibe.
During his second week on the job, we started to look closely at the code.
That’s when we saw it.
Nothing was wrong with the code – in fact, it was excellent– but there was a glaring problem.
China’s timestamp in xCode for the iOS database he was working on.
That’s no weird vibe.
That’s no accidental slip up related to another project.
That’s someone outsourcing work to China, giving login credentials for a client project to a third party we had never met nor corresponded with.
All the puzzle pieces fell into place.
Baffled, I brought Mike into our office to meet with David and me.
We cut to the chase, explained everything, and told him we expected his full cooperation. The check and separation agreement were ready, and if he went out gracefully, we wouldn’t press charges and that would be that.
A few minutes later, he was explaining how he’d been doing this for over 9 years.
He had a marginal understanding of software programming but had never been a coder, and he’d managed to fool two huge multinationals for almost a decade.
He was kind of proud of it, in a strange way.
The weirdest part? After all that trouble, he was only making a 15% margin.
David and I could only respond in bafflement.
After that meeting, we finished his offboarding process. We had to refactor all of his code to ensure there were no malware or security issues.
And we did get the email of the Chinese engineer, because the code was solid and hey, you never know, right?
People: Your Greatest Asset and Liability
This experience caused us to rethink security.
All too often, the biggest security weakness is the people in your company, not the tech.
Look what happened with the Equifax hack. There was no intractable technical problem – someone just forgot to install a software update.
After the incident with Mike, we learned to think about security in a new light. It’s not just about strong passwords and ironclad encryption – if you don’t trust your personnel, your company is not secure.
Now, we have a much more rigorous interview process.
We put all of our engineers through English tests, both written and verbal. Communication is key for a tightly-knit team.
Our interview process has three levels. Every candidate goes through an in-person interview with our head of HR, a member of our leadership team, and our Director of Project Management. If any one of them objects, it’s a no-go.
We’ve also instituted a more thorough code testing process in the interview stage. In addition to purely writing code, we include theory-based work and expect all candidates to explain their solutions, implementation, and thought process – after all, we need software engineers, not just mindless coders.
And finally, we test on general tech literacy. We test both technical and nontechnical people on tools: G Suite, Office, Slack, accounting software (where applicable), and even keyboard shortcuts. We want even nontechnical employees to understand the tools of the trade.
On one level, the increased scrutiny is functional. All of these measures will improve the quality of candidates we select, raising the quality of our entire workforce.
But more importantly, a more extensive selection process helps us get a better intuitive feel for the candidate.
It’s not fair to judge someone at first blush: they might have been acting weird because they slept badly, had a personal problem, or just had a bad day.
I’ve learned to be less impressed by the Stanford Ph.D in Machine Learning and more impressed by the engineer as a person.
Is she thoughtful? Is he a collaborator? Does she watch Rick and Morty?
Sometimes these rudimentary gut tests can be more powerful than any HR department, risk analysis tool, or even coding exam.
At the end of the day, it’s the people that I’m investing in.
Not their output.