How to Master the Tech Interview in These Easy Steps

(This is a cross-post from my personal blog. Read the original article here.)

We IT folks live in very comfortable times. Our inboxes on LinkedIn and Xing are bloated with inquiries from recruiters, who buzz around us like flies attracted by a big pile of feces. Every single one of those recruiters has this one client, who is „market leader in his area“ and is searching for someone like you. I won’t blame them. Recruiters are nothing more than sales people. They want to sell a new employee to a company, and they want to sell this company to you. It’s their job. And yes, most of the big players either have their own recruiting department, or turn to external agencies, because it’s hard to attract new talents.

The problem here is that we (the IT folks) might have become a bit too self-assured over time. I mean, why should I make an effort preparing for this interview at this fancy company? The recruiter said that I‘d be the „perfect candidate“. I mean, they know their client‘s demands best, right? I will grab this new gig in no time! In reality, you certainly won’t get any special treatment. And there are a lot of things to screw up, even if you consider yourself an experienced senior-level talent.

I’ve been conducting tech interviews for a little over 7 years now, including my current gig at trivago, where this has actually become one of my main duties. I still enjoy it very much, but there’s nothing more depressing than some obvious capable people screwing up their interviews, because they were either trying too hard, or treated it too lightly.

So, without further ado, here are my top advices for mastering the tech interview.

(Disclaimer: This is obviously a pretty opinionated view. I might handle things differently than the hiring managers of your favorite Fortune500 company. This is just my personal, year long experience as both interviewer and interviewee. I still hope you’ll enjoy it)

Be F**king Prepared

This should come as kind of a no brainer, but, surprisingly, it isn’t. Being properly prepared for a tech, or, generally speaking, any kind of job interview is in fact pretty simple. It not only could give you a significant advantage in the actual interview, but it also shows your humble interest in your potential next employer. Why should a hiring manager care for you, if you do not care, say, for the business model of his company? Within just 20–30 minutes of Google-research you can find out a lot. A lot about the company, a lot about the department, a lot about the people you’re interviewing with — you name it.

But it doesn’t stop here. Especially when you scheduled a Skype or some other kind of remote call: Please take some minutes to check your connection, your camera, your headset/microphone, and the lighting in the room you’re in. Technical issues are annoying and cannot be avoided 100% of the time, but a pretty good portion of it can with some proper preparation. You’re a nerd, you have no excuse not to do it.

Passion Speaks Louder Than Titles

When I learned something from being a part of the tech industry for 11 years, then that titles are bullshit. Oh, so you’re the Lead Cloud Architect in a five person startup? Cool story, bro! If you want to impress your parents or former schoolmates on LinkedIn with this, you have my blessings. But please don’t add this to your CV, unless you absolutely want to be treated like it in your interview.

Here’s what I’d like to see, rather than titles or diplomas: Passion! Show me your open source projects on Github. Don’t be afraid that they might not meet your (or maybe my) quality standards. Just give some evidence that you care for a something, drive it forward, learn, and become better at it. And if you don’t have any ideas/projects of your own, show me your participation in someone else’s. You do not have to be one of the top contributors of this new hip library or framework, but being an active part of the open source community is pretty good evidence that you know how to master software projects of some scale, and, even better, how to handle communication with all different kinds of people.

And if you still don’t know where to start on open source, I have some kick ass projects that might be interesting to you.

Don’t Try to Show off in Coding Tasks

Oh, poor coding task (challenge, quiz, whatever) — you’re so universally hated for all the wrong reasons. Let me tell you one of my secrets: Asking you to solve a coding tasks does not imply to come up with the most clever solution in the shortest amount of time. Sometimes, the most boring and straight forward solution really is the best of all. And yes, I believe you that, with a certain amount of time, you could solve it with a really clever recursive algorithm, or be really efficient with bit masks, but just. keep. it. simple.

I mean, what do you want to show here? That, in your day to day life as developer, you’re always striving for the most complex solution? That you like cryptic one liners to confuse your fellow team mates? And this is just the “best” case scenario. In almost every other cases, your “clever” algorithm will fail, because of some small bugs or oversights you had, since you were under pressure.

Let me tell you one of my secrets: Asking you to solve a coding tasks does not imply to come up with the most clever solution in the shortest amount of time.

If you really want to impress, start with a real simple solution and try to make it better. And if you get stuck underway, because you simply can’t remember the ordering of needle and haystack of that damn function — awesome! This is the perfect time to demonstrate how to search for help on the internet. I’m not even joking — this is a required skill of every software engineer, which is mastered by only very few to be honest.

Also — and I can’t emphasize this often enough — please share your thoughts with your interviewer during a coding task (even if you’re the kind of person that’s most productive in total headphone-isolation). “Thinking out loud” can help when you got stuck at some point. Trust me, it really does. On the other hand, it really serves the interviewer to digest how you might collaborate in an agile environment, where it might be a (mandatory) convention to pair up with other engineers on your team on a regular basis.

You’re Not the Perfect Candidate. And That’s Okay

Have you ever wondered about those awesome Software Engineers with DevOps knowledge, a Masters in Computer Science, 7 years of experience in at least 3 different languages, and being a pro in handling all different kinds of SQL and NoSQL databases? Let me spoil it for you: Those “perfect” candidates, almost every tech company is looking for in their job openings, simply don’t exist. And that’s okay. I’m not perfect, so you don’t have to be either.

The rule of thumb here is simple: You’re not the perfect candidate, so just don’t pretend to be it. If you cannot answer a question, just be frank and honest about it. No sure what Symony Compiler Passes are, when interviewing for a PHP/Symfony position? The best strategy here is not to come up with some half-assed explanation, but with a response like, “I’ve seen them in some Symfony Bundles I used in my own projects, but, to be honest, I don’t know what they are, and I haven’t yet had the opportunity to have a closer look at them”. Being truthful in those kind of situations could indicate that you might just need one or two more hints to t be pushed in the right direction. Continuing with the example from above, a follow up question from me could be to explain a bit about the Symfony Service Container in general, its lifecycle, and when it could be useful to “meddle” with it. For me, personally, it would be perfectly okay to go from here and meet somewhere half-way.

Here’s a crazy idea: The next time you stumble across this job opening of your favorite tech company that you already read like dozens of times, but always shed away from, because you met their expectations and requirements only 70–80% — send them your application! It’s the year 2017. Chances are pretty good your favorite company already went polyglot in the age of micro services and serverless cloud architecture. So it doesn’t really matter if you haven’t used programming language X or technology Y yet.

Learn and Grow

There’s still a good chance you might fuck it up after all. That’s okay. We all do. You might be disappointed, but don’t be undeterred by it. Take your time for some self reflection. Think about everything, which was good and of course everything that went wrong. And most important: Learn from your new experience. Don’t give up. Keep trying and get better. A rejection might even lead to something better in the long run. But don’t take my word for it — read about the experience of these awesome people.

As I said in the beginning, this is just my opinion based on my own personal experience. You might not agree with everything, so just cherry pick the stuff that seems valuable to you. Just don’t fall for this marketing bullshit about „Code Ninjas“ or „Rockstar Developers“. The real „stars“ of our industry are humble, honest, and passionate about their work.