The Independent Magazine for
Software Development Professionals

Two Ways to Keep Up
1. Newsletter
Our newsletter policy:
No list sharing of any kind.
No "special offers" from "partners."
No "webinars." No "Special Reports."
No junk.
2. RSS Feed
Are you missing out on RSS?
Click to learn more.



Add to Your Reader:
Search Now:
VBScript Programmer's Reference
Discover the full power of VBScript. Windows Script Host, ASP, ADO, Microsoft Script Control, error handling and debugging, regular expressions, classes, FileSystemObject, Dictionary, script encoding, script components, and more.
All content copyright 2000-2006 by the individual specified authors (and where not specified, copyright by Daniel Read). Reprint or redistribute only with written permission from the author and/or developer.*.

A Place to Vent
Tell your tale...
Link Exchange
The PC Weenies
Software Reality
Arabian Developer Network
.NET 247
Programmers Heaven
Developers dex
Letter from Tim Meadowcroft
Received November 7, 2001

Hello Dan,

Regarding language skills testing, as you discussed in "Making the Cut": I'm giving candidates a (C++) language test, but not a "sit in a room and do it" test. My test is more along the lines of a few simple items like "Read this code and tell me what it's doing. Do you spot any errors in it?" Then I use these questions to seed the conversation: "How would you write this code differently? Do you understand the problem this is addressing? Does the code fix the problem or not?" I also get an idea of how they read code (hint: given a function the good ones ask for scrap paper and walk through the operations by hand almost immediately).

I really dislike the "put these 4 operators in order of precedence" tests--in fact I want people that say "It's a bad thing to memorise these details, because the person reading the code may not know them, so I always use explicit braces anyway."--but then, that's how I answer the question in an interview....

I also throw a few syntax errors, style errors, off-by-one errors, resource leak errors, etc. into the code to see how much eye they have for detail, allowing of course for the pressure of an interview. Some things should be in-grained in C/C++ developers, even in an interview. If they mention the typo in the comments...well, it's more about HOW they comment: is it patronising, informative, a throw-away line ("I'll gloss over the typo here.")? If they don't mention it they may be just polite, but by the time you have a dozen of these openings in 10 lines of code it gives at least one chance for a conversation to start, and it gives me an idea of how they operate....

Similarly for testing Awareness I give them a list of names of people and technologies and ask them what these mean to them. We can then use that to chat further: "So, you've read Mythical Man-Month, tell me what you think of it?", "How much of slashdot do you read then?", "If I was new to OO, how would you describe polymorphism to me in a single sentence?", "What kind of books DO you read then?".

None of these are "trick questions", and I tell them that it's not a "you scored 7 / 10" test (I also tell them that I know all the answers because I wrote the test, not because I'm smarter than them), but I find this method useful for helping me be consistent between interviews, for giving a clear plan and structure (and control) of an interview to both sides, and for seeing HOW they address the question even if the ANSWER eludes them, and that's what I REALLY want to know: "How do you react when you don't know the answer (yet)....?"

Tim Meadowcroft
London, UK