(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.