« April 2004 | Main | June 2004 »
May 20, 2004
Technical Interviewing: Pushing the envelope
Recently a very humourous but overall negative online review of a technical interview conducted by a couple of my collegues has caused quite a commotion within my company. The interviewe had obviously not gone well with either the interviewee or interviewers with the former making some very salient points about some key aspects of technical interviewing.
All this made me think about my attitude towards interviewing technical people and my general approach in this endeavour...
I should state upfront that I absolutely adore doing technical interviews and usually only wish for more time to chat rather than the 60 minutes to which we're normally constrained by various factors. I have no formal training for interviewing, but have had a considerable amount of experience (for a developer) over the last 10 years or so.
The original review raised for me a few specific questions about technical interview techniques and the objective of the overall exercise:
- What place do pre-prepared technical questions have in technical interviews?
- This technique was used by one of the aforementioned interviewers and the complexity of the questions did cause some amount of consternation in the interviewee.
In isolation, I don't think this is such a bad thing: although I'm a big advocate of putting the interviewee at ease (in order to ellicit their best performance), surely the main objective of a technical interview is to guage the technical knowledge/aptitude of the candidate. Given that, I can think of no better way of achieving this goal than to ask some questions that the candidate cannot answer, or at least not answer completely.
Fundamentally, you're attempting to find the boundaries of the candidate's knowledge/ability in some direction/problem domain. In essence you're employing a search algorithm over a data structure to find where the data runs out. How you do that is largely up to you, but I would imagine some rough form of linear search would be most people's first choice. Something along the lines of:
- Ask first question... OK, they're obviously way within their comfort zone still - let's push a bit more down the same path
- Ask second question... Still answered quickly and confidently - let's keep ramping the questions up
- Ask third question... Took a while to formulate the answer this time. It sounds like we're getting into less well-known territory. No need to advance so quickly this time
- Ask fourth question... Ahah, didn't really have a good handle on this one. So now I know their knowledge in this area tends to fall off somewhere between Questions 3 and 4
Obviously finding an area where gaining knowledge is so sequential and well-defined would be difficult, but you get the general idea.
- Should the interviewee walk out of the interview thinking they're a shoe-in for the job?
- The answer to this question obviously lies in exactly how the interview went, but I don't think even the most successful interview should leave the interviewee thinking he/she will be starting on Monday morning.
Firstly, if you employ the above approach for defining the boundaries of the interviewee's knowledge in relevant technical areas, then they'll naturally have struggled with some questions. If you haven't adopted this approach, you have no real feeling for the amount of expertise they have in - presumably - areas germane to potential problem domains/technical environments. If this is the case, I put it to you that the interviewer has failed in their role.
Secondly, an HR manager of mine mentioned that it's always a good idea to at least give the candidate some doubt as to how the interview went, should they be refused a position. There's nothing worse than flying through an interview only to receive a "Sorry, given the high standard of our applicants for this position..."-style form letter afterwards. The interviewee would have every right to wonder "what did I do wrong?".
Here endeth my braindump, although there's obviously reams more that can be written on the art of technical interviewing. Many thanks to Jules for helping my consolidate my thoughts on this over lunch.
Posted by Andy Marks at 06:31 AM | Comments (0)
May 08, 2004
A Token Effort
This week, I began working on a task to parse a CSV file (generated from an Excel spreadsheet) and construct an object model based on the contents of the file, whilst applying a simple set of row-based validations to the CSV. "Simple!", thinks I, "I'll just start with my old friend StringTokenizer and go from there..."
How wrong I was!
It seems my friendship with StringTokenizer is one based on deceit as it singularly failed to do what I wanted (nay - expected) it to do. I'll use a simple test to demonstrate exactly where my frustrations lay:
public void testTokenizerNullTokenHandling() {
StringTokenizer tokenizer = new StringTokenizer("a,b,,d,e,,", ",");
assertEquals(7, tokenizer.countTokens()); // fails
assertEquals(4, tokenizer.countTokens()); // passes
}
To perform my validation correctly, I needed to be able to tell when a field in my source spreadsheet had no value, thus producing two consecutive commas. However, my comrade StringTokenizer treats consecutive delimeters as a single one, thus removing all knowledge that an empty position existed.
This causes me all sorts of pain: As each column in the spreadsheet, and therefore field in the CSV, holds data of a different type, treating consecutive delimeters in this manner causes fields to ooze left into neighbouring positions when empty values are supplied.
Interestingly, my second solution returned results slightly more in alignment with what I needed, but still not sufficent. Using split from java.lang.String resulted in a structure that included embedded empty values, but not ones at the beginning or end of the string being processed.
public void testSplitNullTokenHandling() {
String tokens[] = "a,b,,d,e,,".split(",");
assertEquals(7, tokens.length); // fails
assertEquals(5, tokens.length); // passes
}
So, at this point I turned to my own means for a solution, and came up with:
protected List tokenizeSpec(String spec) {
ArrayList tokens = new ArrayList();
int delimeterPos = spec.indexOf(ATTRIBUTE_DELIMITER);
if (delimeterPos < 0) {
tokens.add(spec);
}
int tokenStartPos = 0;
while (delimeterPos >= 0) {
String token = spec.substring(tokenStartPos, delimeterPos);
tokens.add(token.trim().length() > 0 ? token : null);
spec = spec.substring(delimeterPos + 1);
delimeterPos = spec.indexOf(ATTRIBUTE_DELIMITER);
}
return tokens;
}
This way, I get a nice data structure out the other end that I can quickly query for information such as "is there an element in field 3?". Admittedly, I loose the ability to determine how many values have been supplied, but if needed I could abstract this list and method into a class and provide a method to return exactly that.
In summary, I'm not particularly miffed that my passing acquaintance StringTokenizer and it's partner in crime String.split tokenize the way they do by default, but I was a little surprised there isn't some way to override the default implementation to provide such functionality as I imagine it would be a fairly common need.
Footnote: I'm extremely open to comments along the lines of "You, sir, are a fool of the highest order, pray tell what thou didn'tst use the bletch method from the foobar class to achieve your aim?"
Posted by Andy Marks at 08:24 AM | Comments (3)
May 06, 2004
Estimation - and life's other mysteries
Question: When is an estimate not an estimate?
No, it's not a conundrum requiring one-hand clapping levels of Zen mastery to unravel... for I have a simple answer.
Question: When is an estimate not an estimate?
Answer: When it is presented to a customer
For when an estimate is handed over to it's owners, it ceases to become wrapped in the hazy, back-of-an-envelope best guess caveats you lovingly coocooned it in when it was delivered, and magically transforms into an unequivocally absolute truth of startling definition and clarity.
Your estimate has just joined death and taxes as the only absolutes in their universe.
And with their newborn nestled in their arms, the parents go rushing off into the waiting world and proclaim the certainty and precision of the estimate with a confidence and exhuberance only parents can sustain... until that day
That day that every parent dreads...
That day when they realize their little baby is all grown up and somehow isn't going to turn out quite the way they thought they would. What they were positive beyond belief was going to be an estimate they could bet the farm on turned out to be just that, an estimate - with all the inherent uncertainty that goes along with such a thing.
If I could stop beating the baby/parent metaphor with a stick at this point, what I'd give my right lung for is an Observable pattern I could place on my customers when I give them estimates of any nature to allow me to be notified of any communication of this estimate to anyone else. Here's how it might work in practice:
---
(Scene opens on meeting between our hero and his customer)
Andy: OK, I think it's going to take somewhere around 30 hours, but only given the conditions I've listed here... and don't forget that three of these requirements need further clarification by yourself as I've only assumed possible meanings.
Customer: Sure, thanks muchly kind developer (wanders off)
(meanwhile, Andy's coding away in his cubic-hell when from out of nowhere...)
Bzzzzt!
Andy: Aha - my trusty customer is talking about my estimate to their boss. Quick Robin - to the Bat Poles (tm)(r)(c)
Da-na Na-na-na Na-na
(Jump cut to Andy approaching the Customer and their boss having a water cooler conversation)
Customer: ... and the best thing is - we can definitely have this done in a little over 2 days, so there's no risk of it missing the deadline on Friday!
Andy: Gotcha!
(fade to black)
---
Seriously though, this is a continuous problem for our team as we're frequently called upon to make estimates on less than the full facts, and whilst we're usually on or around the money, every now and then we get a statistically significant blip in our estimates and all the underruns don't seem to get anywhere near as much attention as a decent sized overrun.
I'll blog more on this topic later.
Posted by Andy Marks at 09:29 PM | Comments (1)