On Secretly Terrible Engineers

They lurk, unnoticed in the great halls of engineering that are the office strips along Highway 101. “Programmers” not programmers, people who have cheated, stolen, and lied their way through engineering careers without anyone realizing they can’t code. They are among us, incompetent Cylons secretly plotting to undermine us at a crucial time.

Secretly terrible engineers (STEs) are everywhere, and they may be on your very team as we speak.

There is only one way to stop this scourge, one interview to defeat them all. Well, more like a dozen interviews with white boards, but that doesn’t sound nearly as cool. But I digress. One interview to rat these jackals out, to prove just once that no matter how much you did in the past, you will be discovered as the Person Who Doesn’t Know The Big-O Of Trie Insertion.

The interviewer, preparing for this moment for years while waiting for git pushes, stands up and stabs his finger at the interviewee. “I’ve got you!”

Or, at least, I guess that is how this moment is supposed to go, since it never seems to actually happen.

In all my years immersed in the tech industry, I have never once heard a firm talk about the idiots lurking in their own offices. They always seem to be elsewhere. For everyone.

There is a whole cottage industry of articles on how to recruit talented people to startups. Many of these articles are about increasing the recruitment funnel, finding more applications to increase the chance of finding that 10x engineer.

But there is also a darker vein running through these articles, of how to see through the posers and fakes, of how to test engineering skills so that you don’t hire that STE. In this view, the world is swimming in pure engineering mediocrity, and only extraordinarily careful interviewing will allow you to distinguish between fraud and genius.

It’s a paranoid fantasy, a As don’t hire Bs bullshit lie.

The reality is, few professions seem so openly hostile to their current members as software engineering. There is always this lingering caution when interviewing a new candidate that somehow this individual has gotten through every interview process and team review without anyone realizing the incompetence before them. Founders swap stories of “that one guy” who somehow managed to work on infrastructure at Facebook, but was a complete idiot.

Actors yearn to be discovered, while engineers fear it.

I’ve always been curious what all these people have been up to in the Valley. Where do they go all day? What do they do? If we are so surrounded by lackluster talent, how do we build all of these companies that seem to be taking over the world? Are STEs secretly burrowing owls who transform into humans during engineering interviews?

In all my years immersed in the tech industry, I have never once heard a firm talk about the idiots lurking in their own offices. They always seem to be elsewhere. For everyone.

Despite the worst talent crunch that Silicon Valley has ever experienced, we still regularly throw away huge groups of talent for not perfectly answering the latest hip algorithm question. “What do you think of the latest RB-tree research,” your interlocutor asks. “What?” “Buzz! Fail. Or should I say Fizz? Dammit I lost track,” you barely hear as security walks you in shame out of the office.

We can talk about interview strategies and coding reviews and take-home fake assignments all day, but nothing will improve until we have learned to address our own fear that we are going to hire an idiot.

Take an engineer and remove their team, their search engine, and StackOverflow, and yes, they might look completely incompetent. That’s a fault of the interview, not them.

It’s important to realize how strange this model is. Lawyers and doctors are asked trivial questions just a handful of times in their careers during their bar examinations and boards. These fields have the benefit of well-defined bodies of knowledge and monopolies over their skill, so in that regards I guess they have a huge organizational advantage to prevent incompetents from walking through the door.

But even outside of licensed fields, it is odd to engage a prospective hire on technical minutia. Management consultants often have to work out a case study, even though they spend most of their time early on in Excel or PowerPoint. Investment banks follow the engineering firm model during early career interviews, often asking about discounted cash flows and Black-Scholes. But later on, those pedantic questions disappear just as they do in management consulting.

Yet in engineering, we expect people to do live engineering on a white board under stressful interview conditions because, well, because that is what we have always done. Most programmers need StackOverflow, Google search, or Dash in order to be effective, yet you get to an interview and are expected to spontaneously remember the positional arguments for some esoteric function. And we keep doing this even with people who have years of experience in the field!

The difference between finance, management consulting, and engineering is that the first two fields have status hierarchy, and the third one doesn’t. Having the right pedigree of job experience and academic background is sufficient to get a job in the vast majority of fields in existence without too many questions. Simply being at Goldman Sachs for four years is already proof that you can do investment banking.

Yet, we don’t make the same assumptions in Silicon Valley. You can work at Facebook or Google for years, and still start over from scratch with FizzBuzz when you start searching for another job. That is complete paranoia. Nerds are frankly very nervous about status, which Paul Graham argues comes straight from high school. I am not as convinced by such pop sociology, but there is something in the culture that is making us seek out and destroy those losers on our group projects that can’t carry their own weight.

Supposedly some non-trivial group of people fail at simple exercises like FizzBuzz. What does this mean? Supposedly many of these people have worked at major tech companies for years. What does that mean? Is it really true that an engineer did nothing for years? Are STEs really just walking around?

No, but we only realize this when we consider the real context of how engineering happens today. We still act in interviews as if every engineer works independently, when in fact teams greatly affect the performance of every contributor. We act as if engineers should have the entirety of Python’s standard library memorized, when in reality we all use the API reference docs. Take an engineer and remove their team, their search engine, and StackOverflow, and yes, they might look completely incompetent. That’s a fault of the interview, not them.

Thomas Ptacek, a popular engineer and commentator, wrote a long post on his own approach to hiring. One point he made about his interviews stuck out to me. After candidates got through a simple phone screen, “Those candidates got a study guide, a couple of free books, and an open invitation to proceed with the process whenever they were ready. Those $80 in books candidates received had one of the best ROIs of any investment we made anywhere in the business.”

That is the transformation we need in engineering. We need to start with the assumption that engineers are smart learners eager to know more about their craft. No, an individual may not know the specific framework you use for front-end development, but then again, there are so many that it is hard to know all of them. Engage them! Mentor them! Buy them a god damn book!

We need to move beyond the algorithm bravado to engage more fundamentally with the craft. If people are wired for engineering logic and have programmed in some capacity in the past, they almost certainly can get up to speed in any other part of the field. Let them learn, or even better, help them learn.

I am not unbiased here, having gone through this process myself. I started programming in second grade. I wrote tens of thousands of lines of code in high school, programming games and my own web server. I got a Mathematical and Computational Science degree from Stanford and continued coding. I should have been a software developer, but after a series of interviews, I realized the field was never for me. So much hostility, so little love.

No one ever offered me a book. No one even offered advice, or suggestions on what was interesting in the field or what was not. No one ever said, “Here is how we are going to bring your skills to the next level and ensure you will be quickly productive on our team.” The only answer I ever got was, “We expect every employee to be ready on day one.” What a scary proposition! Even McDonalds doesn’t expect its burger flippers to be ready from day one.

That’s not typical in our economy, and as computer science expands in popularity, we need to ensure that the next generation of talent feels welcomed. There are far less secretly terrible engineers than we might expect if we give them mentorship and support to do great work. There is a whole group of secretly great engineers ready to be developed, if only we realized our field’s animosity.