I had a job interview earlier this evening. It lasted about 20 minutes before I abruptly ended it. This was supposed to be a first round technical interview, conducted via telephone and CoderPad.
We go through introductions. I explain my current development and volunteer work and we get to the first question:
Given an input value, determine if it is a power of 10.
This should be an easy question. However…in the last seven years I have not dealt with powers, logarithms, or really anything beyond basic arithmetic. To my discredit, I struggled to recall the difference between a power of 10 and a multiple. To my credit, once I remembered the concept, I solved the problem correctly. This was embarrassing, but I figured I’d make it up on the next problem.
Second question (I think):
Given an array of three integers, determine which two sum to the third.
I don’t really recall this problem because at this point, I was less frustrated with myself and more with the company for asking such boring questions. I used to joke that, if I ever attended another interview where I was asked to code a trivial algorithm like quick sort or depth-first search, I would walk out. I never thought I’d actually do it!
I say this not because I cannot solve the problem. With enough time, or a little time and Google, I can. Arrogance is not a factor, either. I went to MIT, which means I have enough humility to last a lifetime and then some. I don’t like these types of problems because they answer a basic binary question: can the candidate code a particular algorithm. This is a mostly useless bit of information because generally these algorithms have to be simple enough to work through 1-3 in under an hour. In the real world I’d just search Google (Stack Overflow, actually), get the answer and be done. Additionally, these questions rarely relate to the actual work being done. In my time at edX I have had to search a tree once, yet a tree question may have nearly prevented my being hired.
Kyruus and edX are both guilty of this. One engineer at Kyruus likes the Boggle problem. edX, as previously stated, asked me about trees…for my job as a web developer.
The best interview experience I had was at thoughtbot. The first round consisted of an in-person code review. I picked some of my work and walked through it with my interviewer, explaining my testing strategy (of course!) and what motivated my implementation.
The second round lasted half a day. I spent time working with a developer on one of their open source projects. We pair-programmed, allowing us both to get a feel for how one another worked. I also had lunch with the team and got a sense of the office atmosphere.
No time was wasted answering pointless questions about things that can be easily retrieved from online or a textbook. The focus instead was on how I actually work and code.
I’ve read of similar processes where the company gives the candidate a day, or more, to work on a real problem the company wants solved. Some even pay the candidates for their time to avoid potential ethical/legal issues around free labor. I like this approach as it results in useful data and a (potential, depending on the code) benefit to the company.
At this point in my tenure at edX, I spend more time designing and architecting than coding. That doesn’t mean I can’t code. See my Github profile as proof. It just means I don’t necessarily focus my time on the low-level algorithms interviewers seem to love so much, even if they are worthless interview problems.
P.S. To my edX colleagues reading this, I have no desire to leave edX. I just wanted to learn more about the company I interviewed.