I will get to part 3 of my series on becoming an engineer again, but that needs some more time to bake (part 1 and part 2 for those interested). In the meantime, something a little different…

This is one of those posts that was difficult to write, and once written it was difficult to publish - it’s not easy to talk about failure. When I see how people react to such posts from others, in addition to just how demoralised and depressed people can get when they don’t get their dream job, deciding to share myself was made a lot easier.

For context, I have worked at what some people would call “dream” tech companies like Riot Games, early MongoDB and even AOL (no, really, it was quite a cool gig back in the day). I have had what some would consider “dream” roles - starting teams, made principal level as an individual, and now most recently I started as Lead Platform Engineer for Vela Games as we build a game from scratch.

Similarly, I also get asked, occasionally, how I got into the games industry, and the answer is not particularly helpful because the answer is basically: “accidentally”. I used to occasionally check jobs listings at games companies that I admired, but I never actually interviewed at a games company until I talked to Riot Games back in 2014 (and joined them in 2015). That opportunity came about because I knew someone well in Riot, and they vouched for me. There was nothing reproducible about that process for someone else (other than: always leverage your personal network if you have it, of course).

Lastly, before getting to the real meat of this post, I have done all of this from a position of extreme privilege. I am cis gendered, white, educated, my parents gave a stable home and family. I did see some of the “old” Ireland of the 1980s but I mostly lived through the more affluent times that followed. I have also been immensely lucky - I dropped out of college, but rather than having a harder time finding a job, I entered a buoyant market and got one before the first dot com crash made that next to impossible for what would have been my graduating class (2001).

All that is a way of saying that, although I have plenty of failures to share, I don’t know what it is like to be starting from a disadvantage, I don’t have systemic gender or racial barriers to overcome just to get in the door and get an interview. When I give advice here to practice or be persistent I am not ignoring that fact, I just can’t speak to it and will leave that to others.

Real Learning Comes from Failure

After reading the above, or looking at my LinkedIn profile, you would be forgiven for thinking that my career has been one of unbroken success. When I finish at one well respected tech company I easily move to the next, generally do well and sometimes get promoted or try something new, rinse and repeat.

Reality is, of course, far messier. To give you an idea, here are a selection of the companies I have interviewed at unsuccessfully (in no particular order):

• Google
• Amazon
• Facebook
• Microsoft
• Stripe
• Intercom
• Nitro
• Etsy
• New Relic
• Demonware
• Salesforce
• Newbay

There are others, I did a quick scan through my old emails to jog my memory on a few. I have also applied to plenty of positions and not made it even to an interview. Some of the above were unsuccessful because there was a mismatch in terms of level, salary, or because after hearing more about the role I decided not to progress. Those are not what I will focus on here, nor will I focus on the ones where the feedback was too generic (“not a skill fit”), rather I will talk about the hard failures, the ones where I thought I had done well but failed and received genuine feedback that actually stung quite a bit.

Not an Engineer at all?

The experience that stands out to me with hindsight and the only one I will call out specifically here was at Amazon. I had been laid off from AOL after 10+ years and so had not interviewed in a very long time, but this was right in my wheelhouse. I was interviewing for the Web Services team as a Systems Engineer, and I had been doing a very similar role (at a Principal level) In AOL for several years previously. I felt the interviews went well, and I thought I would get an offer.

Needless to say, I had hugely misjudged my performance in this case, and I think my ignorance of Amazon leveling was a blessing. The feedback given was that, and I quote: “your technical skills are just not strong enough to meet our Systems Engineer 1 bar”. I was hurt at the time, but if I had understood that this was for their entry-level bar I would have been devastated. Thankfully, in my ignorance, I put this down to lack of interview experience and I went on to successfully interview with Citrix instead.

To be clear, I have never had an issue with being “technical enough” or had my technical expertise questioned (at least not to my face) when I have been working in a company or in any 3rd party company as a consultant for that matter. The opposite is true in fact, I usually have to deal with impostor syndrome because my opinion is solicited and treated as “expert” or in some way authoritative. Even when I have taken managerial or non-engineering roles, I have had no issue establishing technical credibility with engineering teams. Nonetheless, in Amazon’s opinion, after a full round of phone and onsite interviews, I didn’t even meet an entry level definition of a systems engineer. Ouch.

In retrospect, this also explains why any subsequent Amazon recruiter that got in touch with me immediately disengaged when I mentioned this unsuccessful process.

Failure Themes

Most of the time you do not get specific feedback like I did from Amazon, and having been on the other side of this conversation I know that such specifics are unusual and very difficult to deliver, so for that I give Amazon some credit. It hurts, but at least I know where I failed, what I could improve. Most of the time the feedback is vague, or obvious corporate speak so as not to leave themselves open to being sued. Again, having been on the other side of this, the reason you didn’t get the job might not be you at all, the role can be filled internally, the headcount can disappear, or even though you met the bar someone else is just a better fit.

Hence, rather than more specific failure scenarios like the Amazon example I will give you things that have come up at multiple companies:

• I am not “hands-on” enough (weirdly I have had this for both manager and IC roles)
• Not enough experience (despite multiple years of relevant experience)
• This would be a step up for you, looking for someone that has been at that level already
• Not technical enough (again for both types of roles)

Learning from Failure

Each time I failed, but in particular when I didn’t land a role at a company that I was really excited about, I reflected on why I failed (or if feedback was missing/bad, why I thought I failed) and attempted to do it better next time.

For example: I had previously failed an interview loop (at least partially) because I had a programming language on my resume that I hadn’t used in years. I was asked a pretty basic question on it and failed to answer it horribly. That interview was done right then and there, my credibility was destroyed, and I was flustered by it too. I did the obvious and removed that entry from my CV but I was also far better prepared for when it happened next time.

That next time cropped up while I was interviewing at MongoDB. I was asked what felt like a throw-away question about what my strongest programming language was, and I said Perl, though I did caveat that response with a warning as to rustiness (I did not have this on my resume any longer because I had not used it in a couple of years). When I did the onsite interview though, I realised it had not been an insignificant question - I was asked to interview with the person that had written the Perl driver for MongoDB (gulp) and she asked me to whiteboard a solution in Perl.

Recalling my previous disastrous experience, I quickly admitted that I couldn’t remember the syntax, but would be willing to take a crack at it with pseudo-code. Kristina, being the awesome person she generally is, was fine with that and the rest of the interview went quite well. Eventually, she even asked me to be a technical reviewer for her second edition of MongoDB: The Definitive Guide

Aside: I can’t remember the exact question, but I do remember that it was one of those classic questions where the “easy” solution is a recursive loop that can be significantly optimised in terms of execution time with other approaches.

Similarly, a prior interviewer had mentioned to me (over an informal beer at a conference) that I had talked up my ability to learn quickly. He said that it was something everyone said and a lot of interviewers will tend to tune out, it’s too hard to assess in an interview setting. At MongoDB I had talked up this particular skill, but this time I backed it up with an example: I had read the entire MongoDB definitive guide on the flight over to do the interview. I had only a couple of days notice before I got on the plane to New York, and MongoDB was brand new technology to me at the time. I got quizzed on the contents of the book, asked how MongoDB worked by real experts, up to and including the co-founder and CTO. I’m sure I got some pieces wrong, but again, it’s about learning from mistakes and doing better

The Most Important Skills for Interviewing:

There are table stakes for interviewing well, and some have natural advantages in this respect. If you can think on your feet, articulate your ideas quickly and reason well verbally then you are going to have a big advantage. Like many things, you also get better at it the more you do it. Hence practice is key, but even if you are simply interviewing for practice purposes you may receive feedback that is very difficult to hear, that may knock your confidence.

Hence, I think the three key “skills” required for successful interviewing are:

• Thick skin
• Persistence
• Willingness to fail

You could probably substitute blind confidence for this, but I think that tends to get found out somewhat more quickly. There is one way to work on the above in an interview setting, and that is practice. Now, I am not saying you should just start spamming companies with applications for the sake of it, but be willing to look at those non-dream companies for sure. In addition to giving you an opportunity to hone your interviewing skills, they might surprise you.

I’ve been surprised before myself - I was not expecting to work at MongoDB, I had never even heard of MongoDB when I was contacted by a recruiter and I was not a database expert at all (I was in networking at the time). In fact, when they called I was interviewing with a games company and ultimately chose to pursue the MongoDB role instead, and it changed my life.

Can I help?

If this has been helpful for you, then mission accomplished. If you think I might be able to help more, then reach out and ask. I have done it before, happy to do it again. Whether it is a chat/email exchange, something face to face over coffee (if you are in Ireland, and after COVID of course), I’m happy to set something up.