Now, you may wonder why I think I’m particularly qualified to speak about the interview process. Most people who have opinions about the interview process in particular have it from only one side. The one of being the guy looking for a job. And, most of you only interview when you need a job.
What makes me qualified is that, I help interview people looking for a job and I interview for lots of jobs. In my opinion, you should be interviewing for a job, even if you don’t need one, at least twice a year. I interview more frequently than that. In the last 6 months, I think I’ve interviewed at least 4 times.
So, let me start by telling you what the current interview process looks like, and why it doesn’t work. Then, I’ll move on to the few interviews that I believe captured the information everyone was looking for quickly and how you can move the conversation in this direction regardless of what side of the table you are sitting on.
Over the last several years, I’ve had a chance to read a few Programming Resumes. Or, I should say, TRY to read a few resumes. But frankly, if the Programming Resume I typically see is common, everyone who reads my blog needs this advice. I haven’t seen a barely adequate resume in years. And I’m sick of it. Oh, it’s good for me of course. I know my resume is going to stand out as such a unique work of art compared to the others, that I will get a call back right away. After all, if the competition is so incredibly weak, I don’t even need to try.
On the other hand, as someone who has to read these resumes, I’d like to have something better.
And no, I’m not going to go over the standard “how to make your resume awesome” stuff because evidently most programmers can’t even get the basics down. Seriously!
I’ve noticed a trend recently. Someone will write a post about some technical interview question and someone will write a comment about how that’s such a dumb question that they wouldn’t even bother answering it. I’ve actually been that guy recently. John Sonmez wrote about “Cracking the Coding Interview” and I responded that I don’t do coding interviews. In fact, I wrote a whole post about this. But as John pointed out, this may actually cause you to be limiting your career. You wouldn’t answer that question for a 33% raise? Really? There isn’t anything that could motivate you to consider answering a question that you feel is useless, stupid or dumb?
This week, I saw another post about some technical interview question that someone said he wouldn’t answer. Sorry, I don’t have a link for that one, I wish I did.
And then add to this, the number of useless interview questions I have answered in the last year. Why did I answer them? Because I could. Because the challenge was actually fun.
And so, let’s reconsider the arrogant stance of “Thanks for your time, I’ll show myself out.”
First let’s consider why we might not want to answer a particular question.
Last week, I posted 7 interview questions for C# programmers. I guess I forgot that people can’t see in my brain. So, let me be very explicit this time. The “weed out the losers” questions are meant to do just that. Weed out people who have absolutely no business even applying for the job.
You would be amazed at how many people interview for a job who have all kinds of cool buzzwords on their resume, but when you ask them about it, they know nothing about the subject. I’m not sure if this is the recruiter who is representing them trying to help them out by beefing up the resume to get them in the door or if they actually do this themselves. But, as someone who interviews, I have to have a way of making sure the applicant I’m interviewing is worth interviewing in the first place. Hopefully, I can do this over the phone in less than a half an hour.
So, with that said, if your favorite question isn’t on this list, it is probably because it is a question I would save for some future interview.
Also, to those of you who may think that a technical interview doesn’t really tell you if the programmer is a good programmer or not, I have this to say…
You are right. And when I was a younger programmer and was being interviewed with technical questions, I felt the same way. But now that I’m on the other side of the table, I find that way too often, the people who can pass a technical interview are a lot more likely to be good programmers than the ones who can’t.
And finally, I would not rule out an applicant because he got a couple of questions wrong, or didn’t answer them exactly the way I expected. But if couldn’t answer most of them, that would raise a huge red flag!
So, once again, the place I am currently working has been interviewing for some more programmers and we’ve had to laugh at some of the answers we’ve received on some pretty simple question.
And that naturally got us all talking about good interview questions. How can we tell that the applicant is even worth interviewing?
The following questions are not meant to be THE interview. The questions are meant to shorten the interview process by ensuring the applicant has a basic understanding of the language they will be expected to work with.