Comments on Testing Attention to Detail

Developer Interview Questions: Testing Attention to Detail generated several comments that I’d like to address.

The first one is “I think that your questions test the trait on a superficial and…formal level…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. [Secondly, present 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.”

Those are two excellent questions for finding out if someone knows how to see errors in code, which is one kind of attention to detail.

The other kind of attention to detail is equally necessary and if you’re not interviewing for it, you’re hiring bad developers. Corporate development has tons of hoops you have to jump through to have a stable, standardized system. Things like naming conventions, a well-defined source control structure, coding standards, SQL standards, UI standards, etc…

Although unncessary in small projects, these hoops are what allow a group of 20+ developers to produce software with any manner of efficiency. Being able to recognize these hoops, understand them, and follow them all fit into the bucket of “non-code attention to detail,” which is a trait I am looking for when hiring for our team. This is why there aren’t any “find the bug in the code” questions in my list (although I do ask these types of questions in interviews).

Another comment was “These tests won’t show you if a candidate pay [sic] 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.”

Talking is absolutely much better than silly tests, but how can you ensure that someone is telling the truth? Here’s an example of what “talking” might look like:

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 learned anything from those answers. Most candidates try to give the “right” answer during an interview, which is why you have to ask questions that require knowledge to answer. Asking someone if they pay attention to detail is like asking “Can you write a method in C# that loops recursively through all the controls in a given parent control?” And taking their word for it.

On the “nervous” portion of that comment, I turn to Vince’s reply:

“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.”

Finally, Alexander said:

“[Question] #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.

[Question] #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.

[Question] #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…”

Whew! Where to begin?

Regarding #1, I would indicate these are brand new tables and that the candidate has been asked to write the stored procedure. I would give the business justification if asked, but would definitely be wary of the candidate’s hubris. Finally, if the candidate used column numbers instead of names I would see it as a red flag. Most single answers won’t get you shown the door, but using column numbers is pretty close.

Regarding #2…Really?!

Regarding #3: Asking for the company’s code creation procedure manual is a great answer. I would take that as a sign of someone who knows about corporate development, and who is asking the right questions.

As a closing example, one of the questions I ask during interviews, since we work with Microsoft technologies, is “Tell me about the Microsoft Application Blocks.”

If someone has never heard of them are they immediately shown the door? No.

If someone has worked with every one of them do they instantly get an offer? No.

No question is an all-or-nothing game. Folks who evaluate people for a living through psychological tests, IQ tests, certification exams, college-entry exams, etc…always include multiple questions on a single topic in order to avoid false positives/negatives. The more data points you have, the more accurate your results. Keep this in mind as you interview.

If anything, this discussion has shown how difficult it is to test for a crucial trait like attention to detail.

Start Small, Get Big
Growth Secrets for Self-Funded Startups. It'll Change Your Life.
What you get for signing up:
  • A 170-page ebook collecting my best startup articles from the past 5 years
  • Previously unpublished startup-related screencasts
  • Exclusive revenue-growing techniques I don't publish on this blog
"The ideas and information Rob provides should be required reading for anyone that wants to create a successful business on the web." ~ Jeff Lewis
Startups for the Rest of Us...
If you're trying to grow your startup you've come to the right place. I'm a serial web entrepreneur here to share what I've learned in my 11 years as a self-funded startup founder. Luckily several thousand people have decided to stick around and join the conversation.

For more on why you should read this blog, go here.

1 comment so far ↓

#1 http:// on 09.22.06 at 6:06 pm

Nice to read your follow-up! 🙂 I was the person who suggested talking instead of testing. Of course, it’s better to ask open-ended questions, so the candidate won’t be able to answer simply “yes” or “no”. My suggestion is that you talk to the candidate to know if he focus on details or is more interested on general concepts. You’ll “feel” it, not have a binary answer. Finally — it’s always good to have a mixed team, with different views: if everybody look at the problem from the same angle, they’ll probably look for similar solutions; a mixed team, with different points of view, will be able to see the whole picture.