+972 52-548-6969
Stories from the interview room
It is that time again, we are looking for more developers. And this time I ended up so pissed after an interview I had to call a sick colleague just to vent.
One candidate I ruled out early during the interview process. It was a somewhat sinking sensation in the pit of my stomach as I spoke with the candidate, and I couldn’t get a single actually technical description about what the candidate is actually doing now. A lot of broad descriptions, and a lot of sweeping statements, but no real technical details. But the candidate did know jQuery mobile back & forth, it appears.
The decision was made final when I asked the candidate what web framework they were using. I asked whatever they were using ASP.NET WebForms, ASP.NET MVC or ASP.Net Web API. Note that from my perspective, it is a list in a ascending worth order, and you you are using something not on it, that is a plus (it means you aren’t just using whatever is available, which is nice). So I was quite excited when the candidate said (confusedly) “none of them”. Then it took me putting on my investigative hat and asking a lot of questions about how they are actually doing things before it finally came out that they were doing ASPX.
Not knowing the name of the environment in which you are working with for the past several years… I am not sure what to call it.
At least the candidate was able to let me know how they were using that in great detail. We do stuff in Page_Init, then we have a method that load the data from the database and put it in the ViewState or the Session, then we bind it to a grid, and most of the code is in the grid event handlers. I am sure that the candidate is a great web developer, but I would rather that this particular candidate be great at another location.
The second candidate actually passed our phone screen and was invited to an interview. We have a fairly basic interview process. Some background information for both sides, then a few questions that you need to solve in Visual Studio (and yes, you have full MSDN & Google access) and then a technical portion of the interview that include a system design and a more detailed set of technical knowledge questions.
Now, I am sure that you have heard about interesting interview questions like sort a 100 GB file in a machine 32 bits with 512MB of memory. I admit that something like that would be challenging and interesting. I would probably quite enjoy seeing how people deal with that.
That is not the type of questions that we ask. I asked for a “sort these strings” and a “calculate this tax” programs. I gave the candidate about an hour and a half, alone in a room with VS and internet connection. I am not even asking to implement your own sort, just customize the comparison function and run the standard .NET sort. And do some basic math. The candidate was unable to finish either problem on the time allotted. Now, to be fair for the candidate, the way he solved the first problem was correct and much better than many other attempts that I have seen. Note that the issue was an IComparable<string> instead of IComparable<Item> that caused the issue. It is subtle and something that I would expect an newbie to catch. But this candidate came with full 6 years of experience.
Okay, I said to myself, it is natural to be nervous when doing interviews, let us see what the candidate knows beyond that. The CV mentioned that work with mutli threading. So I began with some questions about that. But it appears that “I only know Thread and BackgroundWorker”. But the absolute clincher was when I asked the candidate about what would cause a high CPU problem and how to diagnose that: “Well, I think that there are special tools that will tell you which process is using the CPU…”
Special tools? Well, I guess Task Manager can be called special, but I am not really sure that I would call it that .And if your experience in troubleshooting stuff never go to the point where you actually look at Task Manager to see what is going on… it probably means that you don’t have meaningful experience in actually troubleshooting stuff.
Comments
Note to world don't interview With Oren or you may be ridiculed on his blog.
This post is a bit unprofessional.
Nice ones! as I am undergoing a similar hiring process here, you have my deepest sympathy. On multithreading, the cutest explanation of deadlocks I ever heard was: it happens when two threads SIMULTANEOUSLY request the locks and he was dead serious about it. The fix was to add some delay to one of the code path. He was so dead serious I though for a minute that I was in some alternate universe...
Can't see he is naming anyone, so no-one is ridiculed in any way. We have had similar experiences when interviewing job candidates, and I think it's nice that Ayende shares his thoughts.
A lot of people think they are experts, but in reality a lot of them are only ignorant of the world around them and too proud to admit they know very little. Good developers are the ones that know they have limits, but also have a "hunger" to expand their knowledge.
"I had to call a sick colleague just to vent." Is it me?)))
I am embarrassed but what is this about: "Note that the issue was an IComparable<string> instead of IComparable<Item>"
You would think these candidates would do the 'smallest' of search for Hibernating Rhinos on the internet before going to the interview and prepare themselves a little!
Oren - I think you need to improve your pre-screening process a little as the quality of candidate seems poor (or your expectation of a good developer are far off the what us mere mortals class as good?). What level where you interviewing for here?
This post is about as professional or unprofessional as any late night show - only that in the show, the people who are ridiculaed are called by their names.
That's all it takes? How much do you pay? :P
I always wondered what an interview with you would be like; I assumed it would be terrifyingly difficult. But given the above, I agree with Jon Samwell that you should probably make it more actually terrifying, and less fluffy, in the prescreening. When I do interviews, I'm much, much tougher, though the problems are similar in complexity (it sounds like). It's the prescreening that will help you the most, I think.
Another thing, I actually don't think nerves should be an issue. I know some people automatically get them, but if they're truly a professional and truly confident and good at what they do, and maybe a little bit introspective and capable, then they should be able to overcome nerves, even if they physically feel them (meaning mentally they get over them, even if their body does not). Most times, when I go into an interview, I'm actually maybe a little overconfident, and then when they ask something really ridiculous like, "Write an algorithm to search this digraph for the least expensive route between Des Moines and Schenectady", and I answer, "Let me just call my friend Dijkstra", that's when I no longer feel very confident that I'm gonna get the job. But questions like what you asked, I'd remain overconfident. :P
Greg, I was very careful about providing no personal details. And to be frank, if you believe that you might be ridiculed as a result of interview with me, I really wish you wouldn't show up. It would cut down the number of negatives I have to go through.
Alex, To my knowledge, I have neither interview nor work with you, so I am pretty sure that it wasn't you.
Unknonw, IComparabe{String} vs IComparable{Item}, basically, he implemented the right interface, but used the wrong generic param.
Jon, That is actually pretty good point, all our interview questions are actually on the blog. And a cursory search should give you them And the current interview cycles for someone with at least 5 years experience. I interviewed some people with 15+.
Kyle, Actually, no, that isn't all it takes. But that is all it takes to get _disqualified_. The people you would hear on the blogs are the people who tripped over the stuff that is there to make sure that people who can't code got through.
Ahh okay, that makes sense. My bad.
Yeah, my focus is always on people who have practical experience, who actually know how to write freakin' code. Which is probably also why I have such a low hire rate. Oh well.
@oren the people who are discussed are likely reading this and they know who they are (or people close to them who knew they were interviewing and can figure out who it is)
Greg, They should know if they are that. And to be perfectly frank, I have no issue telling someone that tries to interview to a senior dev position but can't write a string sort that they are sub par.
I agree with Greg. Completely unprofessional and wreaks of arrogance. This message can be delivered bluntly in person without airing it out in a public space.
horrible post by an employer gloating about rejecting people looking for honest work. not a good look imho
If someone reads this blog, then they have enough experience not to fail such simple interview questions. Also, if they do read this post, then they should be grateful for Oren telling them where they failed.
@JonR If they are asking for honest work, then they should be honest in their CV and their experience. Someone bushing around questions is not honest.
I had an interviewee who mentioned they used SQL Server 2003 on their resume. I thought it was a typo on the resume. When I went through a phone interview with them and asked what version of SQL Server they had used they repeated to me SQL Server 2003. I even continued on and asked if they used any other version and asked "are you sure?" thinking they were nervous. Nope they insisted they were using 2003. So I really understand Oren's frustrations.
I wouldn't call "unprofessional" the fact that Oren named his 2 biggest frustrations.
whoever I don't understand how candidate 1 went through phone screening process.
personally I am getting blocked with technical tasks, whoever I think they are necessary evil to weed out candidates.
I've seen a lot in my experience and to be honest candidate 1 reminds me one of my past dev managers (who used to be a programmer :) )
I am getting frustrated by programmers who know few buzz words but write sh$%t code then blame management for not providing latest coolest tools :)
.. and I can go on :)
As an advise, I'd say to try something else, something like codility. then on face to face grill him through how did he resolved the problem so to make sure he was the one who did the task and not a friend.
I believe Oren just did a huge favor to the candidate(s) he is referencing in this post. To get that sort of insight and honesty only helps you. And to be honest, I don't see the ridicule at all, given he's frustrated about 'senior' developers not even getting through 'prove me you can write professional code' questions. He's not looking down on them over something abstract or advanced. He's making it dead easy for future candidates to not waste his time and theirs. And that is a huge plus. Definitely not arrogance.
I have no problem with Oren's directness and honesty in regards to other people's performance. Depending on where you are from his opinions might sound really harsh.
However, having been through the same experience many times - who are those shitheads, calling themselves programmers, having the guts to actually show up at the interview and totally wasting my time because they don't know anything about programming?
Why get mad about it? Seems like at least 70% of developers out there are useless. We already know this. Just goes to show, resumes don't count for jack.
I really don't see how being honest is unprofessional. If a person can't code then they should find something else more suitable. That's all it amount to. I don't know everything and I am happy to admit that fact. Geez what's so harsh about it? It's more annoying to get some generic reject letter that is politically correct.
As far as seniority, a lot of people base it on the number of year on the job, the truth is there once a certainly threshold is passed (usually about three year or so) the increase in experience amount to very little increase in skills.
Dorin, The first candidate was caught in the phone interview.
In these days on the Internet, I'm not at all sure I do care someone knows how to sort a string. I do care that they know when sorting it needed and how to understand the different sort types and benefits of each, but to remember how to write a shell sort over a bubble sort? Not bothered, that is what search is for. Knowing enough about a subject to know what to search for and what results to discard is more important now IMO
Anon, I think you missed the part where they had full internet access. And if you can do write a sort with Google handy, I really don't want you
I have been on both sides of the table and understand both your situation and reaction. I am a developer, I write code and it is a complete and frustrating waste of my time to even talk to someone who has failed to read the requirements or is out-and-out lying.
On the other hand, I have my own frustrations after reading this article: 1. I came here indirectly. It is only because a commentator mentioned "Hibernating Rhinos" that I found out which company is involved. Where is a link to the company site? Or even a mention of the company name? 2. So I've looked at the company site and might be interested in working with you. (I'll almost certainly be giving your products a tryout). But I see no "careers" or "jobs" link. What are your requirements? What are your open positions? I'm in the U.S., do you not consider remote workers? 3. Regarding the comment "the interview questions are in the blog". Not helpful. The Google search thingy didn't work right away and eventually returned 1330 hits for "interview questions". Not a helpful resource.
Kevin, A long time reader would know all about it. I am not doing a full background for every post. We aren't interested in more remote workers at this point. And you aren't meant to find the questions in a cursory search about my interview questions.
Ayende,, Fair point. In our tech interviews we give full internet access too so if they can't find out how to do a sort with that, then I'd agree with you - they obviously don't understand enough to know what to search for in the first place.
I was just trying to make a point that the knowledge of "how" is not as important these days as knowing "what" it is you are trying to achieve. The days of when you have to remember pages and pages of technical manuals (ah, they were the days of COBOL...) are long gone IMO
Great post. These days everybody call themselves a developer. It's not hard to write decent code and depending on what you do, decent code is really good enough for a lot of companies.
Comment preview