How do you recognize talented software developers in a 30 minute interview? There's a roundtable article on this topic at Artima Developer with some good ideas from a group of well known developers:
Best interview I ever had was with a fellow who was familiar with the product I had worked on at my previous company (he had been outside the project, but knew a lot about it and the people there). It was quite something to have to explain the design to someone who I didn’t know, but who obviously knew precisely what he was talking about.
Yes, I think presentations are probably a VERY good thing for interviews. I’ll have to remember that for the future…
I just completed two days of interviews at Microsoft, and I only had one puzzle question - at the end of the last interview. It was a softball, though. 9 interviews, one puzzle. OK by me.
I know that having to do a twenty minute presentation would scare the cr*p out of me, and I consider myself one of the more ‘interpersonal’ developers.
Certainly, being a contractor I have to be more people-friendly to get a job. I might talk to 20 agents and several clients whilst looking for a position, and I have to sell myself to each one. But I know that for sure that 75% of the developers I have worked with would absolutely not be able do a presentation in a job interview (it’s hard enough getting most of them to say ‘Good Morning’.)
Yet, I have worked with a good many talented developers who would fail your test. If you were recruiting for a marketing role, I would whole-heartedly agree with your mini-presentation approach, but I think you’re ruling-out many good developers if you do this.
But maybe this works well for you - it’s different strokes for different folks, it all depends on what sort of person you’re looking for. Which brings me (finally) to my point - how you interview people depends on you, your company culture, and the role you’re looking to recruit for. You can’t have a definitive list of what to do when interviewing a developer, for example - just do what works for you.
I think your presentation idea is a good one. In fact, that technique was used with me when I interviewed at MS. But I also have to agree with Andy. Making the candidate present to a room full of people would create unneccessary intimidation. When I was asked to present, they a) knew I had done presentations before from my resume and b) only had me present to two people. Interestingly, I found it to be the most fun part of the interview.
Interestingly, I found it to be the most fun part of the interview.
That’s what I’m saying! It should be fun. If you can’t communicate, you’re dead in the water.
I wouldn’t ask someone to present to more than a small group of 4-5 key team members. Putting someone up on a stage in front of a full-blown “audience” certainly isn’t my intention here. That’d be stressful.
is giving presentations part of the job?
If yes great, if not, why bother?
Put them in a room with the people they would be working with, give them a small but representative task and say ‘Do it’. come back in couple of hours and evaluate the results. get feed back form the participants on how it went/what their imnpressions are.
cheers
is giving presentations part of the job?
Communicating with other people is absolutely a part of the job. Any job, for that matter. I don’t think a 20 minute presentation, in an area of expertise of your choice, is asking a lot.
Testing, as you’re describing, is much more stressful.
Presentations… sounds a little too harsh - most developers are geeky types 
Ok, an overgeneralisation, but I’m not sure a presentation is a good idea.
As a contractor I put myself right up there on the communication front, it is almost more important than technical skills, and I could probably give a fair presentation. But I would certainly be happy to give a job to somone who was technically good, could communicate on a one-to-one level, but couldn’t present on their subject.
After all, you need some people to sell the solution to the business, and some people to actually sit down and code it. They don’t really have to be interchangeable…
Honu is spot on.
I’m sure I read somewhere that speaking to a group of people you don’t know (even if it’s a small group) is the surveyed number one fear people have. Giving a presentation sounds very much like a test to me. I don’t normally have to do give them as part of carrying out my job as a developer.
A sit down in an office for an afternoon with a programming task to do sounds like something I could prove myself on, that’s what I do all day… and would probably be doing for you if you hired me.
I’ve had experience of some enthusiastic good talkers, who on a topic of thier choosing, could do quite well. But, sat in front of a computer can’t write code to save their life (not code that is maintainable anyway).
You can test communication skills too, by simply telling the candidate you want them to solve a problem. Don’t tell them what the problem is… wait for them to tackle you, or other people working in the office you’ve put them in to find out what it is they’re supposed to be doing. That’s like real life. I’m rarely given a suitable description first time of the requirements I’m supposed to turn into a working solution.
After they’ve done the task… ask them how they solved it, or why they couldn’t.
-Scott
I have had a very recent internship interview (actually about four or five) with Joel Spolsky’s Fog Creek software. Unfortunately I must say that I am not impressed with their at-best repetitive interview process.
Let me describe the painstaking interview process I went through. It started really awesome, then things gradually declined – you will see what I mean. Our school has already a default application process for applying to internships. Of course, Fog Creek will not have any other way except their own. First, I needed to send an email explaining why I want to work at Fog Creek, as well as attaching my resume. This is, according to them, the first of three steps of their interview process. Immediately after sending the email I in fact received a funny automated response. The second step is a phone interview (of course, they insist on going outside of our standard phone interview procedure for our school and want to set up in their own way). I interviewed with one of their engineers. It was just an ordinary interview. I described some of my past experiences and we proceeded to a technical question. Its about how to design a data structure. We finished with with a QA session.
Apparently I did well enough so I get to participate in the last phase. Fog Creek flew two engineers (one of which I interviewed for) and a PR person all the way from New York. Apparently they think they are the most important people there that day and decide to schedule 3 hours of my day for them without any room for freedom. As a direct consequence I had to miss some of my classes just to attend these interviews. The first was a group interview. We spent one hour sitting there listening to them cracking jokes (I think they thought they owned the place) and talking about New York. At this point I am just plain annoyed. Next came two hour-long interviews with their engineers. Guess what, two more technical questions. They asked one already. Now they are asking two more, which in my opinion adds no value since they are similar in nature (they do actually get to see you write code – but they didn’t need to do it twice). I ended up spending time writing C code on how to dynamically reallocate an static array when its full (which is a small part, but not all to the question – I am hesitant to reveal what the actual question is here). I think I did well enough (hey, if I were to name one thing I am really good at, it is to answer these questions during interviews). I think I managed to finish one of my interviews at the 30 minute mark while the person before me was going overtime.
They managed to select two out of the three candidates, including me for a third interview. This time Joel flew in, a few days later, to do the interview himself. I must say he is quiet a character. Definitely someone capable of articulating his thoughts clearly. I had being reading his Joel on Software blog the day before out of pure boredom, and I admit I found it quiet engaging. So we chatted for a bit, talked about my previous experiences, and then proceeded to move on to yet another technical question (instead of a design or a systems question). It is a little bit different, in that he used “his own language” which is essentially Scheme. I had about four weeks of Scheme experience in a course three years ago so I did know the basics. I didn’t have too many trouble, and finished again around the half-hour mark and was expecting another question. But he didn’t have any (I guess he deviated from the list given above). He then told me it was now time for me to interview him and ask him any questions I may have. Its all good, except I didn’t have any questions! Remember how I had three QA sessions with his engineers (and they told me about Wasabi, and how one of the interview questions stemmed from on how some Office component was implemented when Joel was working there – isn’t this protected secret or something?) and I had that stupid one hour long group interview talking about nothing (but his company and New York). So I told him that I found his blog to be interesting (by mentioning one of its recent entries) and told him I had no more questions. I was hesitant to throw Jeff’s commentaries about Wasabi to him because I was sure he would not like me to question his authority. I have a feeling he didn’t like this very much. You know, it was a neat line “now its time for you to interview me”, and what I did was essentially shooting it down completely by not asking him any questions about Fog Creek. he even leaded me in by asking “do you have any questions regarding the job itself?”. I told him discreetly that I learned a lot about his company during the group interview and did not have any more questions. In the end, the result was that I got rejected at the end of the day as seen from our school system.
But that’s not all. Also at the end of the day, I received an email from one of the advisers. Apparently someone gave him feedback that I did not appear enthusiastic in one of the interviews and apparently I did not do research on the company. While I can’t be 100% sure it was Joel, I had compelling reasons to believe that was indeed the case. I immediately dejected this feedback and portrayed myself as “offended” at such a “blatantly false accusation” to the adviser. I also made it clear [to the adivser] that I was not about to be enthusiastic about some enterprise content management or bug track software that I never used or will ever use in my life. While Joel’s remote assistance idea seemed to be something I could play around with, the fact that I had to pay money to use it beyond the two minute mark completely discouraged me from trying the the first place (this all counts towards research btw). There is one misconception about every job posting. The interviewer always expects the candidate to be enthusiastic about the position. Thats not going to happen with me. never. You want me to be enthusiastic? Give me an offer and give me something interesting to work on. Otherwise we can both move on. I never make false representations of myself during interviews to appear enthusiastic. The only time I will be interested is when I genuinely feels that way – like if a neat idea is rightly so, I’ll do it.
So in the end, after wasting ten hours (not counting the time I’ve spent writing this thing or many emails to that adviser) I did not end up with anything other than a reject from Fog Creek. But then again, I had seven other offers to choose from, and every bit is as bit as good as Fog Creek.
To address a small contradiction about the previous post, I am very impressed about Joel’s outspoken character and his well-written blog, but feels miles detached from his company products.
My favorite interview was with the head of the products development team for my current employer. Essentially he asked me a couple leading questions and then we ended up having a 15-20 minute long discussion of the fundamentals of XSLT. Not only did he ascertain that I was interested in the technological core of the job but I learned quite a bit and got really excited about working with the company.
I was asked How do you measure volume of Bay of Bengal (this is a sea adjacent to Indian Ocean).
Starting with some assumptions I explained the interviewer how I will measure the volume and he was indeed satisfied with it.
There were no more questions.
Having candidates doing a presentation to any size of audience is definitely a bad idea. There are many better ways of testing communication skills and you could find that many talented developers will simply avoid your job because of this requirement.
Sure, having a round-table discussion about something the candidate is passionate about is fine, but stand-up presentation? No thanks. You’re employing a developer, not a PR manager.
Tech job interviews can be incredibly stressful experiences. You have to present knowledge in many different fields, be enthusiastic, show that you can code in ways that you’d never do in real life (on a whiteboard? Ridiculous!) and concentrate for potentially an entire day of separate interviews, all with people you’ve never met before. Adding a 20-minute presentation to the mix is just a cruel and unusual punishment.
it all depends on the role you’ll be taking in the organization. If you’re going to be what I like to call a Black Box developer (ie: You’re given every parameter you need to do a solution and you don’t require any sort of communication whatsoever with the guy handing you the requirements), then this kind of interview definitely won’t work with you. However, in my experience you don’t get to be a Black Box Developer ever. Most of us have to talk to the client quite often, so good communicational skills will always be necesary.
Then of course, this is is different in every country (one would think). In my country, this is the reality. If you can’t communicate properly, you’re dead.
I’ve got over two decades of experience in embedded software development, I write robust code, I write copious and meaningful comments in my code, I’m not afraid to document and I’m pretty decent at it. I’m just as happy writing in assembly or higher-level languages. I know hardware well enough to talk to the engineers, help with designing and debugging. I communicate pretty well and I’m not afraid to say I don’t understand.
But if you told me that I would have to do a 20 minute formal group presentation as part of my interview, I think I’d just cancel it. I’m hiring for the position of embedded software/firmware engineer, not public speaker. Deliberately inducing stage fright for those susceptible for the amusement of you and your colleagues is not a valid interviewing technique, no matter how you phrase it, and doing that kind of presentation in front of a group of strangers is quite likely to accomplish just that.
Fortunately for me, my current boss seems pretty happy with me at the moment.
I can see the usefulness of the presentation idea for some positions, or for some candidates. But software development? You’ll reject a lot of good talent that way. People who can communicate well one-on-one or informally in small familiar groups can’t always do the same in formal presentations in front of groups of strangers.
This is, of course, MHO. YMMV.
The idea of bringing on some new on a trial basis is smart (assuming there are programming tasks that could be performed with limited familiarity of project and cose).
I actually put together a blog post on other techniques that provide valuable information during the interview process:
http://www.customsoftwarebypreston.com/software-developer-interview