+972 52-548-6969
A tale of two interviews
We’ve been trying to find more people recently, and that means sifting trouble people. Once that process is done, we ask them to come to our offices for an interview. We recently had two interviews from people that were diametrically opposed to one another. Just to steal my own thunder, we decided not to go forward with either one of them. Before inviting them to an interview, I have them do a few coding questions at home. Those are things like:
- Given a big CSV file (that fit in memory), allow to speedily query by name or email. The application will run for long period of time, and startup time isn’t very important.
- Given a very large file (multiple TB), detect what 4MB ranges has changed in the file between consecutive runs of your program.
We’ll call the first one Joe. Joe has a lot of experience, he has been doing software for a long time, and has already had the chance to be a team lead in a couple of previous positions. He sent us some really interesting code. Usually I get a class or three in those answers. In this case, we got something that looked like this:
The main problem I had with his code is just finding where something is actually happening. I discarded the over architecture as someone who is trying to impress in an interview, “See all my beautiful ARCHITECTURE!”, and look at the actual code to actually do the task at hand, which wasn’t bad.
Joe was full of confidence, he was articulate and well spoken, and appear to have a real passion for the architecture he sent us. “I’ve learned that it is advisable to put proper architecture first” and “That is now my default setting”. I disagree with those statements, but I can live with that. What bothered me was that we asked a question along the way of “how would you deal with a high memory situation in an application”. What followed was several minutes of very smooth talk about motivating people, giving them the kind of support they need to do the job, etc. Basically, about the only thing it was missing was a part on “the Good of the People” and I would have considered whatever to vote for him. What was glaringly missing in my point of view was anything concrete and actionable.
On the other hand, we have Moe. He is a bit younger, but he already worked with NoSQL databases, which was a major plus. Admittedly, that was as a user of, instead of a developer of, but you can’t have it all. Moe’s code made me sit up and whistle. I setup an interview for the very next day, because looking at the code, there was someone there I wanted to talk to. It was very much to the point, and while it had idiosyncrasies, it showed a lot of promise. Here is the architecture for Moe’s code:
So Moe shows up at the office ,and we start the interview process. And right from the get go it is obvious that Moe is one of those people who don’t do too well in stressful situations like interviews. That is part of the reason why we ask candidates to write code at home. Because it drastically reduce the level of stress they have to deal with.
So I start talking, telling about the company and what we do. The idea is that hopefully this gives him time to compose himself. Then I start asking questions, and he gives mostly the right answers, but I’m lacking focus. I’m assuming that this is probably nervousness, so I bring up his code and go over that with him. He is much more comfortable talking about that. He had a O(logN) solution at one point, and I had to drive him toward an O(1) solution for the same problem, but he got there fairly quickly.
I then asked him what I considered to be a fairly typical question: “What areas you have complete mastery at?” This appear to have stumped him, since he took several minutes to give an answer which basically boiled down to “nothing”.
Okay… this guy is nervous, and he is probably under estimating himself, so let us try to focus the question. I asked whatever he was any good with HTML5 (not at all), then whatever he was good with server side work (have done some work there, but not an expert), and how he would deal with a high memory situation (look at logs, but after that he was stumped). When asked about the actual code he wrote for our test, he said that this was some of the hardest tasks he ever had to deal with.
That summed up to promising, but I’ve a policy of believing people when they tell me bad things about themselves. So this ended up being a negative, which was very frustrating.
The search continues…
Comments
The second guy seems potentially just the kind of person I would look for. Didn't have an ego and showed an incredible ability to learn quickly. You also said he was younger, so it seems fair that he had little experience of the few topics you mentioned.
I guess you are looking for something very specific, and you are entitled to do that. I can't help feeling you were a bit harsh with the second guy, or unable to express clearly in your posts other drawbacks of his.
Craig, I absolutely agree with you here. When I'm saying younger, he was about my age (vs. the Joe was was a few years older). The problem is that if he is doubting his abilities at this stage. And a job interview is the part where you are supposed to be selling yourself the hardest, I'm worried.
Not everyone has a lot of experience with job interviews. Or is a natural sales person. Some people actually try to be themselves on an interview. And depending on the job, you're probably better of with someone who underestimates his abilities than who overestimates them.
That said, if your interview question was the hardest task he ever did and he has very little experience with both html and server side coding, he's probably not a good fit based on just those.
Often the people that under estimate themselves are those that are truly competent. Those that act like they have complete mastery of subjects often do not.
See this recent blog post which I find to be really true: http://www.hanselman.com/blog/ExploringImpostorSyndromeInTechnologySXSW15.aspx
I'll have to agree with Oren's decision. Hiring somebody is a big commitment. You need someone that can both show confidence in his skills and prove that he knows his stuff (talk the talk and walk the walk, whatever you wanna call it)
I get what you're saying here. The point, at least for us, of the interviewing process is to fail (get to no) fast.
That is so you can get to an enthusiastic YES! quicker :)
Anything that makes you have doubts should be considered a red flag.
A miss in hiring is a very costly mistake. I'd rather pass on potential good than hire eventually bad.
@Ayende
Your decision seems more reasonable, although it's still quite difficult to judge without having met the person.
Don't get me wrong, though, you were spot on with the first guy.
@Oren: about the second guy, agree with Tom. Take a look at the "impostor syndrome".
Looks like you sent enough traffic to put the site where the first image is hosted over its quota. I think you were pointing to Fig 17 from the following:
https://web.archive.org/web/20130812193428/http://www.visualspec.org/documents/Architecture_Styles.pdf
@Ayende, you did the right decision.
Regarding the first guy, this reminds me someone who used to work in our place. He did over abstraction in extreme, every design pattern you would think of, he implemented (this was useless of course).
the code looked like Baklava code, after he left, I had to spend 1 month to simplify the over abstraction and make the code more readable.
Regarding the second guy, he's still a junior, you need expert.
Good luck
Your code suffers from a lack of bridge-flyweight hybrid pattern, abstract builder factory for the decorator
Someone that is good at interviewing isn't necessarily good at whatever job they're applying for - two different skillsets for the most part. Oren, maybe you would have better luck with internships? Minimal commitment, see how they work in your team environment, etc.
@Joao: That's why we ask the final candidates to be part of the team for about 4 others. How does the candidate interact with the team and vice versa. Candidates use usually also less nervous that during the formal interviews. We usually show them some of the code (after signing a NDA) and check if they ask questions or even come up with improvements, but the latter is depends on how experience (both in years and knowledge) the candidate is. We're looking for other qualities in a junior than in a senior dev..
But it is interesting to read how other companies take down the interviews and their thoughts about candidates. Although Oren keeps the posts anonymous, it must be weird as an former candidate to read a reference about your interview on a blog..
One difference in considering the second candidate is startup/small business vs large business. It's much harder to "take a risk and train" a junior candidate when you have less than 20 people. That new person needs to be able to immediately pull their own weight.
If you're a hiring manager at a giant conglomerate where the owners and managers are only vaguely aware that your department exists, taking "risks" on new hires is much more "acceptable".
The quotes are important in that last sentence. :-)
"We usually show them some of the code (after signing a NDA)"
http://blog.jpl-consulting.com/2012/04/why-i-wont-sign-your-nda/
That article refers to ideas rather than code, but the same principle applies. If I can look at a snippet of code and own your business model, there's not much to protect. And don't show that code. ;-)
Comment preview