A Thought for Technical Interviews
I would like to share a thought from it.
The interview in its entirety consisted of two individuals presenting me with an intermediate-difficulty problem and having me work through it. The problem was by no means beyond me-- given an hour to sit down and work on it, I could easily solve it.
And an hour is what I got.
HOWEVER:
It's not so much that I needed about an hour as that I needed individual periods of 10 minutes or so to sit silently and think about how I would approach certain algorithmic aspects of the problem as they came up.
Instead, what I had was a laptop in front of me and an individual sitting at my left shoulder and another at my right shoulder, and anytime 30 seconds or so would pass, one of them would prompt me with a remark along the lines of "So what are you thinking?" or "So how are you approaching this?" or "So why don't you start with..."
This ruined any chance I had of completing this problem. I never had enough time to gather a cohesive approach to the problem because the interviewers constantly obligated me into diverting my attention to what they were saying or suggesting or asking.
Imagine if, as we were working at our jobs, every time we hit on a challenging aspect, someone sat next to you and asked you what you were thinking every 30 seconds. How well do you think you would perform?
Interviews executed in such a manner are in no way indicative of a candidate's skill.
Please, give an engineer some time to decide how he should approach a problem. Some of us think very fast and design optimal solutions on the fly. Most of us don't and have to do some trial-and-error to come up with great software. Stop mistaking the latter category for incompetence.
23 comments
[ 2.9 ms ] story [ 60.7 ms ] threadEven when I'm working very closely with colleagues, we often spend long moments of silence thinking and working through issues. It's a part of the process.
On a sidenote this post made me remember a small part of "The Art of Learning" (Josh Waitzkin), where he shares that on chess the opponents would always try to make him feel anxious.
To fight this he always took his time, maybe after the move from the opponent he would just go to the bathroom and take the time he needed to get back on track.
I don't how if this could be applied to your situation too, but I think it might be worth a try. If the situation is anxious too you, just ask for your space and time (maybe even ask if they can give you some solitude).
Silence is gold ;)
1. Getting the answer right is only half the problem here. They are prodding you for your thought process—take that as a sign that that's what they're actually looking for, even if you're wrong. They also want to hear it just in case they need to steer you in the right direction.
Regardless of pairing policies, companies might ask you to collaborate on a problem with someone else. It is typically more productive if both developers are engaged in conversation about it and then working as opposed to doing their own work separately.
2. It's incredibly awkward and tense as an interviewer to sit there for 10 minutes. Also, how do I know it'll only be ten minutes?
If I wanted to know if you could solve a problem in your ideal setting, then I would email you a problem to solve on your own time. During an interview, however, I want to have a conversation. I only have one hour with you and your ten minutes of silence is a wasted opportunity.
He maybe came back like 2 or 3 times to check in, then we discuss what I did, could have done, etc.
The interviewer might find it awkward to wait, but that's not the candidates problem.
Now suppose there were a dozen other candidates all trying to grab control of the keyboard and the interviewers were constantly hollering about which key you should type next interspersed with hollering about which key you should have typed last.
That's your typical youth soccer match when the coaches are amateurs. And that's what you were dealing with, amateurs. That's how you wind up pair programming with three people at a laptop where only one of them types.
Next time answer the question honestly, "I am thinking that you should shut your pie holes and let me think." Well maybe not quite so honestly.
Good luck.
I believe no sane engineers would deny that request.
This excercise in particular took a little more than an hour, because even though I explained a few solutions in various ways he had a hard time actually completing any code. I wrote a whiteboard solution and explained it using arrows and walk-through examples, but he couldn't translate the solution into actual code (using a language of his choice). In order not to break the hour limit we ended up with me writing and explaining code one line at a time for him. I reassured him that it's okay that he can't come up with the code right now, we're not evaluating the result etc.
I turned this candidate down. I feel that while my methodology (close to OP's) has flaws, it does help me with filtering out the worst candidates. I simply can't hire someone that doesn't manage to, with an unlimited amount of help and a generous timeframe, code a Fibonacci sequence in his/her favourite language.
By the way, I failed my very first interview just like the guy you talked about. Complete brain freeze. Luckily, I got an internship and here I am with 7 years of software development under my belt. You probably might not care. But it really makes me wonder about all that wasted potential. Not everybody is as lucky as me.
Put me in a room with a couple of people, a not-real-world problem, a compressed timeframe and tell me to go, and it's a different story. After that time is up, you'll swear I don't know the first thing about technology and go to the next guy.
Why is this? Interviewing psyches people out sometimes. In my case, the act of being judged by my peers gets me to the point where I actually do blank out.
Interviewing candidates is hard. I know because I've done it before. It's much easier to have a boilerplate CS 201 problem that you give to every candidate vs tailoring the interview to each candidate each time. However, I've hired some of the smartest people I know based on this tailored, specific to the business, approach. Most of the candidates I helped hire were still at the company when I left.
If you do boilerplate CS questions you'll get either students right out of CS programs that have these concepts fresh in their minds or people that have been unemployed for a while who have brushed up on their algorithm skills via Cracking the Coding Interview. Maybe these are the types of people you want because they might be cheaper? Most of the software work I've done in the past 7 years has been taking existing frameworks, libraries, systems and adding in some custom logic. Maybe that custom logic becomes a new library on its own and maybe not. You know what's more important to me than the ability to solve Fibonacci? Do you write clean, documented code? What is your ideal software development methodology and can you ship code in that environment? Do you test? Are you a dick or not? What does your gitHub account look like?
Software development employment isn't college. The hiring process shouldn't be a "hazing" as others have stated. I recently had an interview where I as the candidate partially spaced out a problem that was similar to Fibonacci (duh on my part). However, at the end of it the interviewer I think recognized the situation and said "We are all a team here and we help each other out. I'm OK if you are a little weak on generic algorithms in this situation because you know things I'm weak on." That was a good experience and hopefully I'll get a chance to be on that team.
Overall, I'm guessing most companies out there aren't trying to solve "Google" like problems. We should stop interviewing like we are.
Fibonacci is not such a problem. It includes declaring one argument, a handful of variables, one for loop, a couple of assignments and a return statement. And he could not do this with open and explicit guidance.
As he was applying for a senior backend developer position, I can only conclude that morphing complex data structures and calculating shopping carts with taxes, rounding and campaign deductions will be a problem. Maybe I'm wrong, and I should mention that there were additional interview steps and questions where my interview partner didn't have confidence in the candidate, but I really feel that this excercise tells me something. And that's the problem with these kinds of interview techniques I guess. That they do feel very relevant.
However, my challenge was to implement Conway's Game of Life from scratch, which I consider markedly more difficult than Fibonacci.
However, it is indicative of unskilled rookie interviewers. As a candidate you have a lot power in directing the interview process and also evaluate whether these are the type of people you want to work with.
They've got an obvious hiring problem. And it's very likely they took a pass on a lot of strong talent. Suggest circling back with the Senior Exec, share your feedback in a neutral, professional fashion. Ask for a Do-Over and a chance to meet again. The worst they can say is no.