When I started working at AirMap, I had to rebuild the engineering team. There were maybe five people left in engineering, and three of them were quitting. I had a system that I didn’t understand, projects that had stalled, and no people to help me fix it. These problems came from the company scaling. The product had issues, the culture was terrible, and it was all mine. I had many priorities, but the biggest was to hire a team. Without people, we were going to die.
I was exhausted by all the ridiculous hoops I was put through while interviewing before I accepted a job at AirMap. I was determined to be innovative and not do to others what was done to me. I was determined to learn from the mistakes of all those people that interviewed me and build a high-performance team quickly.
My last year and a half at Spark Networks, my previous employer, was all about replacing 20-year-old code in a complete rewrite and restructuring of the business. We reduced the headcount from over fifty engineers supporting the outdated code to just two engineers, and I was one of them. The rest of the team was about 15 engineers focused on the rewrite; I was one of them too. I learned a new programming framework called React-Native, abandoned it but decided to use what I learned on the web. I set up the project for the website, and when I hired my lead engineer, I let him run it. I contributed to the project in code, in leadership, and I also spent a lot of time with the CEO, Daniel Rosenthal, learning from him and executing. Why was interviewing for the same job I’ve had for 5 years, so hard?
The problem was with the people interviewing me. I met a lot of great people and got some job offers, but they were low on the salary. Not that I’m entitled, but I know the value that I bring to a team, and I had issues with the way that number was calculated. I received a job offer that started with: “Gilbert, we loved you, and I don’t want to offend you with this number, but its what we can offer based on your test results.” That’s right, online programming tests. I solved the problem in Java, a language I didn’t know because the tool didn’t offer something I knew. Also, in the on-site portion, I was asked to build an application, again, using Java and ReactJS (but I had not touched react in nearly a year at that point). A person was sitting on both sides of me, watching me code. Was it surprising I didn’t do better?
Then I had a whole slew of interviews with what I like to call computer science trivia, with on the spot coding, without being able to check any of the reference resources. I don’t know what engineer out there doesn’t use Stack Overflow or Google. I generally don’t see any engineer that is presented with a hard problem and always knows the right answer, on the spot. Most people say, “let me look into that and get back to you.” Why was I expected to know all this stuff? On the spot, after explaining that I had been managing resources, negotiating scope with the product managers, and doing the occasional hands-on project for the last year? What other professions out there treat their peers with such hostility? In most professions, having experience, education, and references are enough to get the job. I was rejected over and over because engineers think that it is their job to weed out the incompetent.
Don’t get me wrong; I don’t want to be hired for a job where I would be considered incompetent. Some might say, “Gilbert, testing your understanding of an algorithm is crucial to you working here.” Really? Let’s break that down: You think that something that is taught in college, not used day-to-day is a measure of an engineer’s capacity? Do you not realize that these sorts of questions come from university coursework, and immediately leaves out many self-taught programmers? Like me. More importantly, this kind of information tends to decay over time with lack of use. Think about it. If you’re hiring for an engineer with lots of experience, you rule them out because they are not fresh out of college and don’t remember what you’re asking.
We focus on college coursework and then ask the candidate to optimize it. We’re so worried about premature optimization being the root of all evil, and yet, that is a big part of what we test for when interviewing. Most things work well enough, and we, in practice, only consider optimizing when there is an unacceptable performance problem.
I know that there are many things at which I’m not good. My team is comprised of people with various strengths and weaknesses because they are, well, people. The idea that sets us apart at AirMap is that I recognize that different people are wired differently. Like a coach, I spend time to understand these differences to identify gaps, and then I work urgently to fill them. Engineers don’t work alone. Why do we interview them alone and expect them to know everything?
I have been mostly successful in addressing these issues in my hiring process. I have more work to do. The first thing I did is break up the interview process into three parts: a screening call, a tech screening call, and an in-person interview. This is where I started to innovate.
The screening call follows a particular format where I ask what the candidate knows about us, and then I fill in the gaps. I tell them about our culture, our vision, our purpose, and I provide examples of why some people have not worked out. I then ask them to please tell me about themselves and tell me whatever they want me to know about them. I always end the interview by asking them how much money they’d like to get paid. If I weren’t allowed to negotiate the salary, I’d find another question because the point is to see how they speak to something people often find uncomfortable. If anyone ever tells me, “please discuss with the recruiter,” I tell them on the call it’s not a good fit. The ability to discuss hard things with your team is a huge component of why AirMap has such a high-performance team.
During our tech screening call process, I eliminated whiteboard exercises and replaced them with simple questions (e.g., If you had to build an e-commerce platform like Amazon, how would you go about doing that?). I’ve found that the candidate will gravitate towards what they know best. It also allows me to see if they are a big-picture person or focus on the details. It shows me how well they do with vague requirements, along with their ability to ask questions and push back. The exercise ends with one of our engineers showing how they might do it. This portion is meant to be slightly confrontational because we’re providing direct feedback on the spot. This directness is to see how well they deal with input, and once again, we test their ability to have a “difficult” conversation.
Once the candidate makes it to the in-person interview, we want to hire them. We’re meeting face to face to talk again about the same things and do the exercise again. This phase is meant to be a validation, not a trap. It also allows us to the opportunity to learn who the person is; it is much more important than what they are. Here, we discuss the principles of our culture deeply and confirm alignment. I have many examples of people whom I’ve hired that wouldn’t traditionally be “qualified.” Because of who they are, they intrinsically seek to learn, don’t tolerate problems, and have a passion for setting up the team to win.
The results have been fantastic. I always like to say that AirMap has a small team relative to the problem we’re solving and yet, we go out there and outperform the competition. I know because, in the unmanned air traffic management industry, we collaborate in standards groups to perform experiments. In these experiments, we’ve had to carry the workload for some big-name companies. Their stuff didn’t work when it came time to test the results of our collective research efforts. We have projects happening in parallel all over the world, we deliver, innovate, outperform our competition, with a smile and with the satisfaction that comes from pushing the boundaries of what is possible. All because we didn’t let ourselves get restrained by the fallacies in the Software Engineering world.
Podcast: Play in new window | Download
Subscribe: RSS
Leave a Reply