in reply to Interview with a Programmer
A candidate should be given some practical tests to solve.
When I interview for database programmers, I usually start with background and theory knowledge. I show them a Entity-Relationship diagram and ask to describe the links between some given tables.
Then, I ask the candidate to write me some quick SQL code to solve a practical problem, using that diagram.
If (s)he comes this far, then it's time to talk about programming languages, and I ask to solve the same problem as before, only this time not manually, but programmatically, and I want to see a flow chart or some pseudocode before the actual code is laid out.
Later, we discuss the code, and this is when programming language details come up.
A few years ago I used to do the opposite, starting with discussing programming languages and then painfully skimming through elusive answers to come to the sad truth that the candidate didn't have the faintest idea about databases.
Latest time I hired, I was able to detect inflated skills within fifteen minutes for each candidate. Some of them, challenged with the E/R diagram, found a quick excuse to leave immediately.
This strategy gives me more time to dedicate to the more promising applicants, since I know that when we come to the "chatting" part, some evidence of skills already exists.
As a final test, to determine how good a candidate is, I ask him/her to document the code just written.
I don't know if this is the best strategy, but it worked for me.
When I interview for database programmers, I usually start with background and theory knowledge. I show them a Entity-Relationship diagram and ask to describe the links between some given tables.
Then, I ask the candidate to write me some quick SQL code to solve a practical problem, using that diagram.
If (s)he comes this far, then it's time to talk about programming languages, and I ask to solve the same problem as before, only this time not manually, but programmatically, and I want to see a flow chart or some pseudocode before the actual code is laid out.
Later, we discuss the code, and this is when programming language details come up.
A few years ago I used to do the opposite, starting with discussing programming languages and then painfully skimming through elusive answers to come to the sad truth that the candidate didn't have the faintest idea about databases.
Latest time I hired, I was able to detect inflated skills within fifteen minutes for each candidate. Some of them, challenged with the E/R diagram, found a quick excuse to leave immediately.
This strategy gives me more time to dedicate to the more promising applicants, since I know that when we come to the "chatting" part, some evidence of skills already exists.
As a final test, to determine how good a candidate is, I ask him/her to document the code just written.
I don't know if this is the best strategy, but it worked for me.
_ _ _ _ (_|| | |(_|>< _|
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Interview with a Programmer
by Anonymous Monk on Dec 27, 2008 at 07:17 UTC |
In Section
Meditations