In my decade long career I've had the opportunity to interview many different programmers for many different roles. Everything from front-end web developers to full-stack senior developers and even an occasional intern or two. And more importantly than just interviewing them, I've had the opportunity to hire and work with them.
So today I'm going to go over a few key points as to what I look for in a programming candidate. I won't pick any experience level in particular as this is more of a general guideline really.Whether you are a junior programmer or a senior developer, the following still apply.
Pure unflattering honesty
Don't vent mind you. I don't need to hear about your troubles with your neighbor. Just in general, the less lies are thrown around, the more casual and comfortable everyone is. This is something that even I myself struggled with when I was first going out interviewing for programming jobs.
Do you know this language?
Me: Absolutely! like the back of my hand...
And then every question going forward from that moment turns into a confusing QA where everyone starts sweating and such. Honesty is amazing. If you don't know that language, which one do you know? I mean, if you know one well, you're bound to learn others Id' wager, so let's talk about those.
Remember this, if you do not know how to do the job, you won't be able to do the job. And then you'll either have to face months of stressful projects or you'll end up looking elsewhere, which can overall hurt your resume as you hop around from job to job. If you don't know a few topics, that's totally fine. If you don't know any of the topics that are being covered in an interview, then just maybe that position isn't right for you. Be honest with the interviewer, but more importantly be honest with yourself.
Extracurricular activities are important
I've met many programmers that have hated programming outside of a professional work setting. But they do it for the relatively higher paychecks or because they paid for the college degree and now don't really many other options. And you can tell they dislike it, because once they leave the office they won't look at code until they are forced to. To me, this is equivalent to a Chef that hates food. Because one of the coolest parts about being a programmer, is that you get to build stuff for yourself. This company is willing to pay you six figures for your skill set, and not putting that to use for yourself is madness.
I'd estimate that 1/20 programmers that I've interviewed for web developer positions had no personal websites or projects. And if they do, it is something put together using Wix or SquareSpace. The reason you need a personal website, is because I don't want to look at websites that you worked on for past employers. And I'll explain why. Because most of the time, you didn't build that website yourself. It belongs to the company and you work on the website. What you do on it, I have absolutely no idea.Maybe you worked on the contact page, or maybe you helped to build the awesome admin, which you can't show me due to legal reasons.
But if you show me your own project, I immediately know that you built the entire thing. And there can be a much healthier conversation had on the overall topics. In this scenario, you have more freedom to discuss the technology stack that you used, which is much more beneficial to you than getting asked an assortment of random questions. And also, personally, I enjoy programming. And if I am going to spend months working with someone, it would be nice if they have a few side-projects that can be discussed during lunch.
Non fancy keywords required
Some people enjoy throwing out a Polymorphism reference here and there. But it is not required. Unless the project you'll be working on is 100% based on the concept, then yes, yes it is required. But for the most part syntax talk isn't my thing. I Google keywords everyday just as every other developer does and I don't expect anyone to memorize every single class name and element and to give me a description of each. I've had to do this at interviews and it's just an awkward exchange of someone spitting out memory fragments.
Being able to explain complex topics in plain English is an important skill to have and to master. Particularly because at most jobs you will be required to communicate with non-technical members of your team.
Ask questions
It's a good sign when a candidate wants to know more about the position, or about the company in general. Again, it shifts the point of attention from random coding question, to something that you have more control over. Ask about the technology stack or about the culture. Don't ask if the person enjoys their job. That's a loaded question. A good question to ask is if you will be working on multiple projects while you are there. If the answer is yes, then know you are in for a more challenging time, but that you will learn alot more. And if the answer is no, then more than likely you will be doing maintenance on some currently existing project.
In all honestly, this might not be a job that you would enjoy, which is also why it is important to find out as much as you can early on. Ask subtle questions about company culture. Maybe you will be working weekends for months on end, it happens. Or maybe you have 3-4 program managers that you are accountable for during the morning 2 hour long daily standup.
The goal isn't to say 'Yes' to the very first offer that you get, even though that's the mentality with most job seekers. The point is to find a job that you can do and that you will enjoy while you are there while you grow your skillset and while you earn a living.
You don't have to love the company
Many candidates feel like they have to have some type of bond with the corporate structure that they are applying for, and I for one find it creepy. I once worked for a pretty random magazine publisher which asked me why I wanted to work there. My very awkward response was because I have magazines and I like them alot. We both laughed. Realized how stupid the question was. And I got the job.
Not to say that you can't love my company. If I were applying to a cookie factory, I'd gladly let them know that I eat cookies and lots of them and that I want to eat all of theirs. But it's okay if you don't. Your need for finance and food vastly outweighs my companies vanity, I assure you. And unless I myself own the company, I don't really mind either way whether you do or do not enjoy it or what they do.
And if you do enjoy the company, then have a concrete answer as to why and be able to back it up.
Be yourself at some point
But most importantly, if you're going to be joining the team, I must know you as a person. Not the collection of predictable answers that one researches the night before. And so normally I do end interviews with very random questions about your life. What do you do that doesn't involve technology? Favorite food? What kind of laptop/computer do you have and why? Not that these questions make much sense to the job at hand, but they tend to shatter, if only momentarily, the interview feel and allow the human side to reach out a bit.
More than likely, you will be working closely with the developer that is interviewing you. And these will become your future friends in the not so very distant future. You will go to lunch with them daily and you will bring them home to meet your family. Be yourself and see if the job is a match to you. And if it isn't, then keep looking until you find the right fit.