The worst interview question ever
Friday, February 26, 2010 at 08:39AM I left Red Hat for my current job at Socialware last month. I had been thinking about leaving for some time, but the whole process happened quite quickly. It pretty much happened entirely over a week of forced vacation at the end of December. (something I still consider to be corporate theft of vacation time, but we'll leave that for another post) I knew pretty quickly that that company was a good fit. It was an early stage startup with good people and some good technical challenges. T
I've talked about this before, but one thing I haven't told many people is that earlier that month I had talked with another company. I won't name names, but it's a large company that I discovered was starting to offer cloud services. I've been very eager to start working with amazon-style cloud services, and this company was a provider of those services. That would be a perfect fit for my JBoss background, so I tried to make contact with this company. I was very worried about the size of the company, especially since one of my complaints about Red Hat was how big the company is.
I made contact with a technical person in the cloud services group, and I was excited about talking to him about what they were doing to see if they might be a good fit for me. Before the we were scheduled to talk, I got a call from an HR guy at the company. I was hoping to avoid HR, and any company that would have a hiring process that involved an HR guy as first contact was probably bigger than I really wanted to deal with. However, their technology is interesting enough that I decided to give it a go anyway.
When he calls, I explain a bit about my background, what I'm looking for and why I specifically contacting the group in question. Everything was going well, and I thought he should be able to tell that I was a serious candidate who really should be talking to the technical person that I was already scheduled to talk to. So I was surprised that out of the blue he asked:
So, tell me. Have you ever worked with any design patterns?
Uh, yeah.... I think I may have heard of design patterns before. In fact, I'm sure that I had mentioned at least a few in talking about some of the things I was working on. I answered politely in the affirmative, barely able to contain my surprise at the question. The next question was perhaps the worst interview question I've ever been asked before.
Can you name a few of the design patterns you've used?
Seriously? You want me to read you the table of contents of GoF to you? Really? I was speechless. I was literally unable to find the words to respond, a real "There's no emoticon for what I'm feeling" moment. I'm pretty sure I set my phone on the table and just stared blankly for a minute.
I try not to be a prima donna about these things, but it's kind of insulting to ask. Maybe you could ask a regurgitation question like that to an intern candidate who really might have no practical experience just to see where they are, but beyond that it's really a waste of everyone's time. Any company who would put up that kind of nonsense as a front line HR screen is just not the kind of company I'm interested in working with.
If you really feel the need to screen for the basics, at least have the courtesy to ask it in the context of actual work and experience. There are plenty of ways to ask a basic design patterns question in the context of an interviewee's experience if you are actually paying attention. And if the HR guy isn't technical enough to carry on a low-level screen then perhaps you should assign a technical person to do the job?
I have no problem explaining what I've done or demonstrating that I'm not just full of hot air. For example, at Socialware we did some white board coding and softball Java problems that required only a modest amount of non-book experience. But those were more jumping off points for discussion and a test of communication skills than a textbook screen to see if I could recite a list of things or get the specific answer. I had fun talking to the guys, and I felt they were people that I could work productively with.
Maybe I'm making too much of the thoughtless question, but I really think companies should think a bit about how the questions they ask represent their company. If you can't be bothered to engage a candidate in a meaningful discussion, then why will that candidate want to work for you? My perspective is that at a job interview, the candidate should be carefully interviewing the company at the same time. In the case of the un-named large company, they failed my screen.
View Printer Friendly Version
Email Article to Friend
Reader Comments (31)
I think you are a prima donna on this issue. They don't know you from anything. Lots of programmers have had jobs for years but don't know much about programming. I talked to someone who had been programming in Java for 5 or 6 years and they said something like "I never know if I'm supposed to build one or two classes for an app that I write". On paper this person looked like they were experienced. After talking to them, their way of programming in Java is something we wouldn't want to deal with.
So, yes, you are being a prima donna for not answering the basic questions. It's a good thing they "failed your screen" because with an attitude like yours I think you would fail my screen too. I want a team player who is willing to work with the slower developers and mentor them, not someone with an attitude who can't be bothered with that stuff.
John Smith, you're an idiot.
Norman is the author of successful books on Java technologies and has worked as a core developer of innovative technologies at JBoss for something like 5 years. He's not a guy who spent 5 years building internal web applications using JSP like you and your team, and his resume would have shown that. If the person interviewing Norman doesn't already know something about the projects Norman has worked on, then that person doesn't have the necessarily level of expertise to interview him. Simple as that.
Yes, he's a prima donna, because he's earned the right to be. In his position I would have thanked the HR guy for his time and quickly hung up the phone. Because there is no way in hell I would want to work for any company which insulted me like that. And no, John Smith, you don't want someone like Norman or I on your team, because (a) we're more senior than you, (b) we think you're an ass, and (c) your project bores us to tears :-)
And I think Norman's post is interesting and shows why large companies have problems attracting the most talented people. The most talented people *are* often prima donnas, and don't often have time for timewasting bureaucracy. That's why Norman is working at a startup company, and why big companies are filled with seatwarmers like John Smith.
I think you can very easily find out what someone knows by actually engaging them in a conversation about their work without resorting to "read my the table of contents of the design patterns book". That doesn't tell you anything, now does it? How about "name some collections classes you've worked with". Really, did you learn anything at all about the person?
If you want to know if the person knows about design patterns, ask them to talk about their work. Do they talk in terms of patterns? If you ask a question in terms of known patterns, do they understand you? Doesn't that tell you a lot more than if they pull a list of pattern names out of the air? Do you really know anything more than you started with if they can? Do you really meet many developers with any experience at all that couldn't name some design patterns quiz show style?
I totally get your sentiment, but this has nothing to do with working with "slower developers" or being a mentor. I think you are projecting your own bad experiences onto what I wrote. This is simply an issue of a very poor approach to interviewing. In my 15+ years of coding, I've never heard such a poor interview question.
Oh, and John, I've been working in Java for 10 years and Smalltalk for a couple of years before that, and I also often don't know whether I should write one class or two (or three, or four) to solve a particular problem. Figuring out the right granularity and division of responsibilities can be one of the *hardest* things to figure out up front when writing a new application, especially in an unfamiliar domain, and something I usually get wrong initially. Good design usually evolves slowly over time, after multiple passes of refactoring.
I guess this problem doesn't come up as much for you, John, since it is not such a big deal in your JSP/scriptlet internal web apps.
I hope you let that company know what a bad job they did of attacting you to their company. I used to work for a pretty large financial institution where us techies noticed volume of CVs slowed to a trickle and the some of them were so bad they were only fit for kindling. As a group the senior techies revolted and told HR that we would screen the candidates and do the initial interview before they got anywhere near them. It was a lot of extra work we didn't need but the alternative was being understaffed or ending up settling for the duffers that HR let through the gates.
> If you want to know if the person knows about design patterns, ask them to talk about their work. Do they talk in terms of patterns? If you ask a question in terms of known patterns, do they understand you?
This is my take-away from this piece. I admit I have asked exactly this many times as a jumping-off point into real discussion. I can tell in 1min if the person has the level of knowledge I'm looking for. One problem (addressing Gavin's post) is that we don't all have the luxury of hiring someone with half Norm's reputation, let alone someone who has published books. So I don't think this question is really that terrible but it is obviously a really bad choice for a candidate like Norm. A company hiring someone like that should realize they're being interviewed as much as they are interviewing the candidate.
That said, I really welcome this perspective and I'll adjust my questions in the future.
Norman - really sorry to see you leave JBoss and I wish you the best in your ventures.
Peace.
Sounds like a typical HR interview to me. I think that many companies hiring developers, large and small, just don't have tech savvy HR folks.
HR has passed along resumes to me of candidates that they had cleared for further technical interview, but many times these individuals are simply awful.
Have you read your own comments? That's exactly how you come off here Gavin.
Honestly, if you're had any significant number of interviews you'll find that:
a) HR people are clueless
b) HR are the gatekeepers at certain companies
c) If you want to work for companies where this is the case, suck it up, answer their stupid little questions and move on to the next stage of the interview process. Laugh about how dumb HR is with the next interviewer.
Yes, any technical interviewer should know who Norman Richards is. If you expect an HR drone to know (or care) about all the great work you've done, well, I've got some great property in Florida to sell you. Remember, if you go to work for this company you're not going to deal with HR all day, you're going to work with the technical guys. So why let what HR reads off a sheet piss you off?
Heh, and I'll continue to be an ass in all future responses to "John Smith"s who tell talented guys who worked on my projects for years that they aren't "team player"s, "have an attitude" and are "prima donna"s. I'll be the judge of that, not some asshole anonymous blog comment poster who has never met or worked with Norm. I'm protective of my team. That's not going to change. Sorry if you don't like it.
Quite of a discussion and some non polite answers. I think Norman forgot he was in front of some une who simply read a bunch of questions, directed to screen people with very little knoledge in the software business. Most certainly the poor guy has the least idea what is JBoss, Seam, ReadHat, etc, etc, and who is Norman. He reads the questions and writes out the answers. And that took Norma by surprise because he, most probably thougth the interviewer had a good knoledge of software bussiness. Ive seen quite a few of this kind of situations and some times I really enjoy them (thats becouse I'm mean). I think you should all calm down and stop throwing stones to each other. And yes, Norman has all the right to behave like a prima donna if he wishes to (I think he should not). He gained that and much more.
Wish him lots of luck, good work and joy in his new job.
The HR guy probably wasn't technical at all, that shouldn't be a surprise. He was almost certainly asking a question that was given to him by someone who was, along with a list of acceptable answers. The purpose of which was to determine if you had any technical knowledge at all, not to determine the depth of it.
As an interviewee, you found it insulting. Think of it from the other side though. If you are already working there, would you want to waste even 2 minutes talking to someone who couldn't answer the question? Let HR do it, that's what they're there for! Leaving the technical people to do their stuff rather than sort through the riff-raff that pad their resumes would surely be considered a positive virtue.
Lot's of good responses. I'd like to add that although I'm critical of the lazy approach to screening used by big companies, I can understand it. It's simply not the kind of company for me. However, even if you are going to go down that road, the person doing it should have sufficient people skills and technical skills to perform the screen for the candidate. This was a company that was looking for a senior engineer - not an intern. Would you ask a sales manager to "name a few sales techniques you know"? Would you ask a managerial candidate to "name a few companies you've heard of"? Seriously - think about the insanity of those questions. How about "name a few operating systems " or "name a few java classes"? Those questions don't tell you anything, and asking them shows the interviewee that you and your company are too lazy to prepare and to impersonal to care.
I've interviewed countless job candidates myself over the years, and I know that it's not always easy to sort through people. However, when I did screen/interview someone, I always tried to have the courtesy to carefully read their resume, look at at their work and ask relevant questions if their resume/letter looked interesting enough to get in touch with them.
I think if you saw the candidates coming in you'd have more sympathy.
http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html
Gavin King: if Norman Brown is anything like you, I'm totally correct in my assessment. I just hope you don't ever find yourself unemployed and need a job because all an employer needs to do is search for your name to find that you attack people you don't agree with and generally treat others like crap.
The HR person was trying to do their job and trying to be helpful in this situation and Mr. Brown doesn't have the time for him. I think that is a problem. Yes, the HR person is clueless about technologies, but all the HR person was trying to do is narrow down a stack of 100 resumes to 50 before involving the technical people to keep them productive. If he can't deal with that, he shouldn't get the job because he will have to deal with people that aren't as smart as him in the work place...like Mr. King.
One more thing Gavin King - it is hilarious to me that "an idiot", someone who is not "more senior than you", some who you "think you're an ass" and who's "project bores us to tears" can piss you off so much. Insecure much?
John - I was sure you weren't actually reading what I wrote. So I'll take the fact that you can't even get my name right (the thing in big bold letters at the top of the page) as confirmation that you are simply not paying attention. I really think you are projecting your own experiences here.
Although it doesn't make a difference in this case, I would point out that the HR guy wasn't just going through a stack of resumes. I had already used my network to make contact with the hiring manager in the specific group I was interested in and had scheduled a time to talk further that person about the specifics of what they were doing. The HR guy didn't even need to be involved, as far as I was concerned. (in fact, he was only cc'ed into the conversation at the very end, I presume as a formality)
But I don't think that's so important. Even if I was just a resume in a stack, it's still a horrible way to go about things. The HR guy was most assuredly not just doing his job. That's the problem - he wasn't DOing any job at all. Reading off a list of things does not reveal anything. It's a lazy, stupid question, and it confirmed all my big company stereotypes.
Hey Noramn, I hope you will keep contributing to the seam project.
Enjoy at socialware.
great post.
Who is Norman Brown? Another one of your aliases?
Interesting. Have you actually tried searching my name?
So let me get this straight, your advice is that when I criticize people online and call them names, I should do like you, and post using an obvious alias? Sorry, not my style. Like I said: you're an idiot, and a cowardly one at that. If you wish to disprove this conclusion, let's have your real name.
Actually no. You really do like making up stuff about people you've never met. But I think I'm better at it, Mr. JSP/scriptlets Man. :-)
Hey, if you want same evidence of insecurity, you're the one getting defensive over criticism of your *alias*! LOL
Gavin, you of all people should know that a name doesn't matter. It is well known that we posted under assumed names all the time!
You really do like making up stuff about people you've never met. But I think I'm better at it, Mr. JSP/scriptlets Man. :-)
Regardless of what Smith does or doesn't do, you are as guilty of making stuff up about people you have not met as he is - you have no idea what he does.
You are making a fool out of yourself because people know who you are and read your blog - making grandiose statements about yourself does not look good. I've had problems in the past with non synchronized access to hashmaps within hibernate and the resulting infinite loops (could easily have been you who committed that but who knows), and i've worked with a (subsequent) google developer who liked to talk the talk but completely screwed up a basic byte stream handling component. The best developers i've encountered in my career have typically been the ones who do the job and carry a large dose of humility; the worst (in terms of quality of code and bug generation rate) have frequently been the ones who considered themselves some kind of coding superstar.