![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
This week I've been doing phone interviews for programmers. Today we had two come in for a face to face. I was asked to come up with a "test."
My test design goal was something under twenty minutes. Rather than having them create a program from scratch, I thought it would be more revealing if they fixed something that was broke. Of course, the environment holds your hand for debugging, so I needed some way to judge competence that didn't simply involve bug chasing.
My brainstorm was to write code that, while almost entirely functional, stunk to high heaven. The applicants would be asked to refactor it. It took me about an hour to come up with some really, really ugly code. I included some great sins like cut and pasting connection strings, connecting to the database as often as possible for as long as possible, never closing connections, statically allocating arrays, bad names, every bad practice I could fit in a page full of code.
My ugly code
If you understand this code, please take a moment to fix it. I really don't think it's that hard for an experienced programmer. Let me know what you think. Then, read on.
Refactoring this proved depressingly easy. Just ignore the bad code and rewrite the thing. You essentially need code that takes a database command and returns a list of strings. There are many ways to do this, with collections its simple and even with datasets and dynamic data adapters for the terminally lazy.
Put the connection object in a method call, create database commands from the know connection, use a database join to do the work instead of all those stinking loops and you're there. Here's my solution.
Possible optimizations included caching the author result set and referencing the author ids from a dictionary object. For the GUI inclined, three tables could have been dragged into dataset and .NET would have generated table adapters and the foreign keys associations automatically. The entire dataset could have been loaded into memory; not vary scalable, but quite functional.
My candidates, both with excellent interviews, one with a great resume, the other fresh out of school, failed this miserably. In half an hour, neither got off the ground. Did they need more time? Am I missing something? I've been doing this a long time, so maybe I don't appreciate the difficulties newer eyes see. I really don't know.
My test design goal was something under twenty minutes. Rather than having them create a program from scratch, I thought it would be more revealing if they fixed something that was broke. Of course, the environment holds your hand for debugging, so I needed some way to judge competence that didn't simply involve bug chasing.
My brainstorm was to write code that, while almost entirely functional, stunk to high heaven. The applicants would be asked to refactor it. It took me about an hour to come up with some really, really ugly code. I included some great sins like cut and pasting connection strings, connecting to the database as often as possible for as long as possible, never closing connections, statically allocating arrays, bad names, every bad practice I could fit in a page full of code.
My ugly code
If you understand this code, please take a moment to fix it. I really don't think it's that hard for an experienced programmer. Let me know what you think. Then, read on.
Refactoring this proved depressingly easy. Just ignore the bad code and rewrite the thing. You essentially need code that takes a database command and returns a list of strings. There are many ways to do this, with collections its simple and even with datasets and dynamic data adapters for the terminally lazy.
Put the connection object in a method call, create database commands from the know connection, use a database join to do the work instead of all those stinking loops and you're there. Here's my solution.
Possible optimizations included caching the author result set and referencing the author ids from a dictionary object. For the GUI inclined, three tables could have been dragged into dataset and .NET would have generated table adapters and the foreign keys associations automatically. The entire dataset could have been loaded into memory; not vary scalable, but quite functional.
My candidates, both with excellent interviews, one with a great resume, the other fresh out of school, failed this miserably. In half an hour, neither got off the ground. Did they need more time? Am I missing something? I've been doing this a long time, so maybe I don't appreciate the difficulties newer eyes see. I really don't know.