March 16, 2008
Six years is child’s play to what this baby has seen:
She’s a keeper.
I’ve learned and grown and experienced so much these past six years.
and to those who’ve expanded my world over the years–Milenko, JR, Allan, Eric, David, Edgar, Joe, James, Dru, Mark, Eric, Ji, Amy, Martin, Kisung, Lauren, Corey, Belynda, Tara, John–
and to the Brownie Beer Bear and the Bowling Pin of Justice–
and to those random guys at Kate O’Brien’s Friday evening who lent their unsolicited “signatures”–
and, of course, to Andy, Nick, and Narendra–
March 11, 2008
Reg Braithwaite in Let’s make this personal, please:
Or perhaps you say, “Test-driven development is fantastic, but most programmers are too busy to write tests.”
Those are all valid concerns for somebody, but how about we let those people speak up for themselves, hunh? […] instead of debating things based on our perspective of their experience, let’s debate things based on our own experiences and our own honest likes and dislikes.
Great point, as usual, from reg. We must learn to not assert others’ preferences or motives, particularly as a mask for or support to our own.
Let’s go further. How about we argue things based on actual research?
I think that definitely qualifies as “better sense.”
March 5, 2008
I’ve been thinking about interviews lately. At my new job, I hope to be able to build a team, and I’ve been asking myself how to improve on past experience.
I’ve always been a bit uneasy asking basic coding questions. A colleague of mine asks basic coding questions simply to weed out so-called “architects” and “team leads” who haven’t done any actual coding in a long time. In that respect, they’re fair questions. And, amazingly enough, they do weed out a number of so-called senior programmers. (How is that possible?)
But even perfectly reasonable answers can be held against the candidate, because then the interviewer (and his colleagues in the ensuing post-interview discussion) get to dissect every last bit.
“Well, that part there, it isn’t so well optimized…”
“He hesitated a bit too long, like he had to think about it, but it’s a basic part of the language…”
Pretty much the only way to knock the socks off an interviewer with a basic coding question is if you’ve heard and answered the question before. Which is cheating, isn’t it? (When I interview, if I’ve answered a question before, I feel inclined to say so.)
And as an interviewer, that makes me uncomfortable. I want to know what you’re capable of and imagine how you’ll fit into and enhance my team. So you might not have a lot of experience with language X. But do you know how to optimize SQL? Have you studied the great resources available on building large-scale web sites? Can you learn new material quickly and present it to your team in a way that everybody groks?
So, here’s what I’ve been contemplating. It’s a three-stage interview. Well, maybe four stages, depending how you look at it
Stage 0. At the end of the phone interview when the decision has been made to bring a candidate in, they’re asked to learn a new technology. I’m imagining giving the candidate a choice of two or three fairly complex things. For example, how does Java’s
ConcurrentHashMap work? How does Lucene answer queries? Etc.
Stage 1. Day of interview. The first thirty minutes to an hour, the candidate presents this new technology to the whole team, and answers questions. This gives the candidate a chance to shine and build confidence before being grilled. It breaks the ice. (If the presentation doesn’t go so well, the interview is over.)
Stage 2. Day of interview. Normal interview rules apply.
Stage 3. After the interview, the candidate is asked to consider his answers during the interview, and given a couple of days to improve on a coding or design question by e-mailing the hiring manager with an improved, or even totally new, solution.
What I like about this:
- Learning new things is one of the most important parts of any gig, and yet it’s absent from 99.99% of interviews.
- Team members should give frequent presentations to each other. This gives the candidate a chance to be just another team member doing what team mates do.
- Rarely is a programmer satisfied with their first solution to a problem, particularly if they were rushed. Yet candidates almost never get a chance to show how they go about revising their solutions.
- The structure and pacing of the “real interview” part of the interview need not change. Nobody needs to rethink their standard questions.
- By giving the candidate more chances to shine, the whole team is more likely to give an enthusiastic up or down. Rarely will you still have a bunch of “maybe”s (which, by default, should be no–but who feels good about that?).
- Worst case, you waste forty-five minutes of everybody’s time in a useless presentation that imparted no knowledge. Like that never happens during the normal course of a week anyway.
- Once the ice is broken and the candidate has built some confidence, he’ll probably give better answers the rest of the interview. Which means: you’re free to scrutinize his answers more thoroughly.
What do you think?
March 1, 2008
If you’re like me, the first time you heard the FizzBuzz programming interview meme, you tried it yourself in your favorite language.
“Reasonable solution, less than one minute, works. I’m not a loser, at least. w00t!”
But in Oh, Go Ahead. Overthink FizzBuzz., chalain takes it to the next level, with a random number-based solution…and a publicly-available Ruby gem.
“Maybe I am a loser, after all.”
 Unless your first inclination is to try this problem in Java, in which case you’re seriously in need of an intervention.