About: Interviews

Time for a story:

In the current tech scene, there is a huge demand for software engineers. With that being said, my first time interviewing for a software job didn't go very smoothly, to say the least. My interviewer, who I remember as an asshole (though he really wasn't), asked me about classes and objects, instance variables and class variables, scopes and other stuff that we've only skimmed the surface about in this book.

Either way, all of those things I was asked about were reasonable to expect from a software engineer to know regardless of how junior I was. But I didn't know shit. I barely ever heard of the term Object Oriented Programming at the time. I was a true noob.

A few years go by, now I can definitely answer such trivial questions about OOP (Object Oriented Programming). But guess what? This time when I interviewed for a job, I had no idea how to write a damn function to return the Fibonacci number at the N-th place.

God dammit, I thought to myself. Why is it that last time I checked I was a pretty good developer, but still couldn't figure out how to land a job as a junior developer?

Well in hindsight, I realized, all those interviewers always asked the same questions -- find the largest number; build a T9 dictionary (that annoying thing that would help(?) us text before we had smartphones); do the Fibonacci thing; sort an array; write a method that will calculate if a number is a prime; and a few other questions I'm not going to list here so I can still trick you when you come interview with me one day.

So at this point you must be asking yourself: "Why don't interviewers come up with new questions to test those interviewees more accurately?" Well I thought the same to myself, but it turns out it isn't that easy to come up with your own set of original interviewing questions. What most programmers do is solve pretty benign problems in their daily jobs, so they'd basically have to be pretty good researchers to "invent" one, and most interviewers just aren't. So they recycle questions they were asked before, or questions that someone else had posted on a blog that cycled on Hacker News (you'll see) under a title such as "Interview Questions We Ask at Twitter." There's nothing wrong with that. It's just that by expecting you to know the answers to those questions all those interviewers test is your ability to memorize. Which shouldn't be undermined. Remembering how to iterate over an array will definitely be useful in your job, but keep in mind that all programmers, no matter how good they are today, at some point also saw the Fibonacci question for the first time. Do you think that when they did they had the solution to it impromptu? I doubt it. It's not an easy one to answer when you're in the midst of a stressful interview.

For the curious, here is what most interviewers want you to get to in regards to the Fibonacci algorithm:

function fibonacci(n) {
  if (n < 3) {
    return 1;
  } else {
    return fibonacci(n - 1) + fibonacci(n - 2);
  }

Go on, plug it in your Console, and make sure to play with it a bit so you understand what happens here. Whatever it is -- it was at one point hard on everyone to understand it.

In fact, when solving problems, we all rely on previous knowledge. Had the interviewer not known what the Fibonacci sequence is, could they solve it then? Had they not known or worked with recursion (when we call the fibonacci function again from within itself in the code snippet above), could they solve it then? Fuck, let's go even further: Had they not known about basic algebra, addition, and subtraction, would they then be able to solve it?

This isn't an attack on interviewers for being tricky, but rather to show you that there's absolutely no need for you to feel bad, or ashamed, for not knowing how to solve a problem. This is not a gauge for your intelligence. It does not reflect on how good a programmer you are or will be. In most cases, it just means you have yet to see this question in a textbook, on a blog post, or utterly fucked it up on an interview before. But you will fuck it up one day. You'll get it all wrong. And then you'll think about it, and then you'll solve it at home with the help of the Internets, and then you'll subconsciously forget that one day you had no clue how to solve this, and then you'll turn into an interviewer that asks the same question expecting everyone to have had the same experience she had; and the cycle continues.

What will make you a good programmer, really, is having the ability to apply knowledge from a vast array of fields and experiences in your life. I don't think there is a formula to being a good programmer. But I'm pretty sure your life smarts are going to be of more value to you in this field than anything you will have read in a book. Including this one, duh.

So whatever background that you come from, or how shitty your experience has been so far, you have a pretty good chance at programming. Just apply what you've learned in life. My short life experiences have given me an immense amount of help in my career as a problem solver. Who knows how much your experiences will help you.

Table of Contents
Home