I have an interview coming up really soon because I can't be self-employed and living by our own terms forever unfortunately. At least not yet, I'm working on it. And after many many interviews in my life, I know what to expect from it. And I'm not looking forward to it, not one bit. This is when I need to reach back 10 years into my college computer science classes and start to remember those keywords that I was told were so important. Except that they aren't and because of that I've forgotten most of them. I don't think I've ever turned to a co-worker and said "that's going to require some inheritance right there". Or "wait wait, we're adding a new menu, what's the Big O of that?" But for some reason, those are the questions that get asked when you're looking for a job. Over and over again, I've had to answer these questions, and it sucks the life out of me.
In 90% of my interviews, the pattern of questions normally goes something like:
- What is inheritance?
- What is polymorphism?
- What is a thread?
- Why is a thread not a process?
- What is Big O
"Big O is a kick ass anime, that's what". Yeah, that humor won't fly sometimes. So that's normally how my interviews go. Interviews like those are my kryptonite. And not because I don't know the answers to the questions, but because as soon as those questions start, I know that I don't want to work there. I get an idea of how development is treated and it tells me that this is a keyword centric place and not an innovative company. At the jobs that I have gotten and have worked, they went a little differently. I was asked about previous projects that I've worked on and my own personal work. Some even went as far as asking me about projects that they're currently working on and how I would tackle them. Those were fun interviews, that unfortunately aren't the norm.
Picking up those keywords
So to prepare, it's time to start Googling some textbook definitions and jotting them down. Getting them down in the simplest form is always best, because if you answer in a complex and thorough manner, you will get asked "What do you mean by that?" more times than brain cells lost answering it. I've been stuck in that never ending loop and you just want to floor to give way beneath you so that they feel sorry for you and just give you the job. I just want to stop and ask, "how much actual inheritance is used here?" and maybe I'll get a chance on this next adventure.
I've yet to have an interview where I'm not asked to implement a sorting algorithm, or even worse to thoroughly discuss one. This is an easy question for someone to ask and there are multiple answers usually. Bubble sort is a popular one and simple to memorize. Again, to me, this is an annoying question. The only time it would make sense, is if you were applying for "Sorting algorithm specialist". At that point, you'd better have your sorts down. But I don't. I apply for web developer. And there may or may not be sorting requirements sometimes.
The puzzle place
This doesn't happen as often as the other mentioned types of questions, but it does make an appearance sometimes, and my my my is it awkward to sit there and try to figure out how many pieces of gum will fit in a phone booth. There's a rumor online that companies like Google ask puzzles and riddles to potential employees during their interviews, and as such many companies feel that they should do the same. Does Google actually ask those questions? I have no idea. But I do know that they can't possibly help in any way, unless the goal is to make the interviewee feel as awkward as possible. There is no tip here. You either saw the answer somewhere, or you just don't know.
This is not how you find the best talent
But it's the current culture that we're sitting in. Just Google "Good interview questions" and you'll get back list after list of these questions, and that's the biggest problem. People aren't giving interviews based on their companies needs, they're doing it based off their laziness and the ease of just looking up what someone else thought to ask. This is the equivalent of hiring a doctor and asking them to name every bone in the body. It's unnatural and only manages to make people fresh out of college with no real work experience look like pros and it makes actual programmers who know how to problem solve look like they have no idea what they're doing.
In a better world, you would tell me what your needs are and I would tell you what I can offer, and that's it. Based on that, and how well we got along you can make a choice to hire or not. But wasting 3 hours of someones life with 5 or 6 different people at different times asking about heap sorts and for loops doesn't help anyone. Unfortunately, because that is not how things work, I will be forced to answer such questions very soon and on the positive end, it's more interview experience and I will get a chance to write about it here for anyone interested. So let's see how it goes.
Found this useful?