Comments on: Developer Interview Questions: Testing Attention to Detail

By: jvvw

jvvw — Fri, 22 Sep 2006 12:29:25 +0000

I’d be wary about giving any questions with deliberate mistakes in because if I were a candidate who paid attention to detail I probably wouldn’t go and work somewhere that appeared not to! How you test attention to detail is an interesting problem though.

By: rwalling

rwalling — Wed, 20 Sep 2006 23:49:49 +0000

Thanks for your comments, Alex. The SQL question is not intended to test someone’s SQL ability – surely this join is too trivial for that. This question serves the sole purpose of looking for attention to detail (in this case, a simple spelling mistake). Keep in mind no single question can give you a sure-fire method of evaluating a candidate. That’s why you should ask several questions along the same line to gauge a candidate’s abilities. A user does have 1 or more addresses, therefore the UserKey is in the Address table. If we added an AddressKey to the User table a user would have 1 and only 1 address. We want a 1 to many relationship (not 1:1 as you mentioned).

By: http://

http:// — Mon, 18 Sep 2006 06:21:22 +0000

Just on a sidenote: A company that makes me take a test on writing a query on a poorly designed datamodel and only worries about the spelling might not be a good company. Clearly the relationship between User and Address is such that the user has an address (not that the address has users) – therefore the addresskey should be on the usertable to begin with ! Even more important would be the question how good the reuse of that address really is. Why not keep them in one table as that relationship is clearly 1:1 to avoid your frontend developers having to build not needed functionality?

By: http://

http:// — Thu, 14 Sep 2006 13:39:23 +0000

OK, this may just be me but the “the candidate is nervous and therefore can’t think” line of thought really grates on me. I just don’t buy it. I need someone who can analyze problems and make decisions under pressure, because during the course of a multi-million dollar software project, pressure situations come up. But mostly, the line of thought bugs me because even though I’ve had plenty of interviews where I’ve been nervous, I’ve always been able to think the interview questions through and reason them out.

By: rwalling

rwalling — Wed, 13 Sep 2006 22:11:44 +0000

Thanks for the really great suggestions and feedback. I plan to implement several of the ideas that have been presented in the comments. One comment of my own: Bringing things up conversationally doesn’t work very well because it’s too easy to give the “right” answer. Q: “Do you write good code?” A: “Yes” Q: “Do you show up for work on time?” A: “Yes” Q: “Do you focus on details?” A: “Yes” You haven’t really learned much from those answers.

By: http://

http:// — Wed, 13 Sep 2006 18:32:10 +0000

In my current company (and previous lives) I’ve seen the greatest benefit (and detriment) of attention to detail in the project planning (PM) – especially at the beginning of a project. This is because (IMHO) people with attention to detail tend to gravitate more towards thinking through and figuring out as much as possible at the outset instead of a project (don’t get me wrong, I’m not a PM evangelist, I believe in a well balanced approach to all thinks, and I would never claim that PM is a sliver bullet.) So testing with the scenario option is a good plan, and I also appreciate what another poster says about “talking it out” instead of trying to mathematically figure it out with questions (not that the author suggests this, but I see how it’s inferred.) So here is my sample scenario: give the candidate a rough functional specification document for a piece of software (or anything for that matter) and see how detailed their response is. The more detail, the more they’re paying attention. Caio, A fellow worker

By: alexander

alexander — Wed, 13 Sep 2006 17:32:32 +0000

Since these questions seem hostile to the interviewee, it’s important that they be armed with the proper responses. #1. Ask why the company doesn’t already have a stored procedure in place for the join? Ask for an explanantion of the business process being supported to clarify if an inner join is really necessary. Finally, write the inner join using column numbers instead of names since the company hasn’t been able to normalize their spelling. #2. Ask for a copy of all applicable HR documentation detailing the use of the information you’re about to provide. Insinuate that the company is using the hiring process as a cover for the collection of email addresses to sell to spammers. #3. Ask for a copy of the company’s code creation procedure manual that documents this process (They do have this stuff written down don’t they?), read it back to the interviewer. Alternatively, begin your description with “wake up in the morning, get out of bed…”, provide a minutely detailed schedule of everything that you would do leading up to the creation of the Hello World application. If the interviewer claims that you’re including extraneous details explain that completion of your morning meditation is an integral part of writing good code. Then branch into an explanation of your holistic world view and why we shouldn’t eat corn (“The kernels are crying man! Can’t you hear them crying?”). #4. This is actually a fair question. Answer it as best you can.

By: Christopher

Christopher — Wed, 13 Sep 2006 16:22:30 +0000

If some company managed to produce an interview question like #1, I would interpret it as incompetence and would want to find the exit quickly. see thedailywtf.com for more great interview questions like that!

By: http://

http:// — Wed, 13 Sep 2006 15:29:38 +0000

These tests won’t show you if a candidate pay attention to details. They only show that, on that given moment, he was nervous. It is much better to talk to them, and bring this topic during conversation: “do you focus on details? are you more interested on general concepts?” etc. Talking is much better than silly tests.

By: http://

http:// — Wed, 13 Sep 2006 10:20:52 +0000

What most ‘looking for details’ questions tend to be are just like “where’s waldo” games – if you can spot him, well enough, but then why? Here’s a simple technique – Ask him to write a simple program, in whatever language you were recruiting for, and have him/her present it for different people – himself/herself, co-programmers, boss, other departments like marketing, and clients. If you’ve been through the motions, you’d know how one version would not work for all. Then, you’ll see how detailed or adaptive he/she can get.

By: Paul Norrie

Paul Norrie — Tue, 12 Sep 2006 21:33:59 +0000

Some interesting ideas Rob. Once I did try missing a line number from a code listing the candidates had to code review. The line itself wasn’t missing, just the line number skipped the number 20. No one picked it up. On reflection, I believe it was partly that this was for new graduates who had probably never read code on paper before, let alone with printed line numbers so they never even were cogniscient of the numbers. I do like the idea of having them review or write a small routine that has a lot of ‘what-if’s to be handled.

By: Oli

Oli — Tue, 12 Sep 2006 17:06:37 +0000

I disagree with the “paper form” test if it’s going to be given DURING the interview. I know I would rush through it to get it over with, so we could get on with the REAL interview, because too many times those forms are just to satisfy some bureaucratic fantasies. That and if I see a company is forcing me to write out by hand something I could have typed (or that could have been copy-pasted from my resumé) then I wouldn’t be entirely sure they knew how to use computers to run their business.

By: Aleksey Linetskiy

Aleksey Linetskiy — Tue, 12 Sep 2006 13:37:06 +0000

I totally agree that attention to detail is an important trait, and definitely should be tested during an interview. However, I think that your questions test the trait on a superficial and, I would say, formal level. Here is what I would suggest: – Give the candidate a problem which is prone to off-by-one errors; make sure that, if the proposed solution has the error, the candidate is aware of the possibility of the error and knows how to test. – A problem with potential “special cases” – something along the lines of writing a function that calculates 1/x, but a little bit more complex, so it will not be that obvious.