Guest post by Tuhin Chakraborty, Hacker in Residence at HackReactor
The almighty technical interview has struck fear in the hearts of budding engineers throughout the history of computing. Some see it as an antiquated, inefficient, even useless procedure, that simply tests a candidate’s ability to answer a very specific type of question and not much else.
Others still reject it entirely, favoring methods like “try before you buy”. But despite rising opposition, there is little debate the technical interview is still the industry’s most popular evaluation tool.
I recently had an interview at Pandora for the position of Senior Software Engineer. The interview was a classic example of a grueling technical interview. It took five hours with a different person, one after another, grilling me at the whiteboard as I tried desperately to solve the problems they threw at me while hiding the sweat puddling at my feet.
The fourth interview stood out most. The interviewer, we’ll call him Ben, was introduced as one of Pandora’s best engineers. Still reeling from the morning onslaught, I was shaking in my boat shoes.
He walked in, grinned, looked at the whiteboard — a tangled slop of circles and lines, the aftermath of a graph traversal gone horribly wrong — and then said, “They still ask this kind of stuff?” Was he joking? Making light of my ruined state?
“I can’t do any of that kind of stuff,” he assured me. “I can write code, but I could never do that.”
He then proceeded to ask me a question many orders of magnitude more difficult than what I’d just been asked. It was a question that, as he put it, had never been solved.
That night, I cried.
But alas, that is the nature of the game we software engineers must play. Rather than fight or lament it, it is better to realize this can work for us rather than against us.
Anyone can get improve their interview game, and the more the skill with which you play, the more you will win.
Hack Reactor is a software career accelerator that understands that game very well. That’s why we, the students, spend two weeks of the 12-week program — 14 hours a day, six days a week — studying algorithms and data structures.
We spend an hour of every morning — often the first waking hour of our days — for twelve weeks, practicing the kinds of problems I was asked at the whiteboard at Pandora. We do linked lists, binary trees, n-ary trees, red-black trees, prefix trees, and tree traversals: depth first, breadth first, pre-order, in-order, post-order traversals. And then we do sets, and queues, and stacks, and sorting algorithms. Quicksort, merge sort, insertion sort, even bubble sort for fun, on the days we’re feeling cute. And of course, don’t forget hash tables. Don’t ever forget hash tables!
Brian note: Barack Obama thinks Bubble Sort is the wrong way to go :)
We also do pair programming at Hack Reactor, which teaches you to speak eloquently about the code you’re writing to someone you don’t know. This is an invaluable skill for an engineer. It means when I’m at the whiteboard and I have no idea what to do next, I can vocalize my thought process and give insight into the decision trees I’m traversing in my head. It also teaches you how to be a human — a surprisingly rare trait among engineers. We have such a tightly knit community here at the school, we understand what it’s like to love the people you work with, and to work as a team to build something beautiful. Those are the intangibles that make a difference when you’re sitting in a small room trying to convince someone they should hire you.