I wanted to have a few words about interviewing for mid-level and senior developers. I do this for my company as one of my many functions (including software architect and lead developer). The reason I feel compelled to write is disappointment. I just cannot reconcile how good some resumes look and how poor the results are off the paper.
When I interview, I *never* *ever* go the puzzle/trick route. I think those have very little to do with our jobs at best and give misleading results at worst. To me, you should focus where the big cost items are in software - in its (lack of) structure and in its (lack of) flexibility. Does the code smell?
It is how easily the software can be changed over time that determines its real cost.
So when I interview, I first establish that they have good grasp of object orient design fundamentals. Then I focus on the key area of "best practices." Does the candidate understand when they are creating a mess? Do they recognize conceptual pollution when they see it?
To ascertain this, I give them a take home (java) "test." I want them to not feel a great deal of time pressure (when was the last time your boss dropped a programming task in your lap and said it needed to be done in 20 minutes?). I give them overnight to complete the test, but in reality it should only take them 20 minutes.
The actual test is short. It's a two page code sample for them to critique. I tell them that their boss is interested in hiring the developer of that code and boss wants their feedback. The test shows the following kinds of problems:
- embedding strings directly in code
- mixing of abstractions
- blocks of code commented out (with no other explanation as to why it was commented out)
- the use of public virtual functions called in a constructor (a questionable practice)
- complete lack of comments
- errors in relationships (coder assumed 1:1 when its really 1:N)
- missing abstractions (over use of string data)
- over-reliance on open-ended integers (instead of enums)
I don't consider this tricky questioning. It basically boils down to me having developers that don't keep me awake at night wondering what messes they are making. I feel that a competent developer ought to be able to get most of this almost by instinct.
So why do 90% of the candidates not make the bar?
9 comments:
Some very good points - you always have to test a coder by getting them to code!
Also, beware of relying too much on phone interviews, especially for more senior coders that might need to go out and meet customers.
Interesting approach (critique code) Allan. You're dead-on about avoiding the approach of "on the spot, make them sweat" which in my opinion is purely sadistic. :-) I've been subjected to them myself far in the past...
It would be interesting if you post an example of this and your analysis. I'd seriously give it a try.
Definately an excellent way to test coding skill. However, I would be careful to judge a coder that does not do things exactly your way, since "best practices" aren't always set in stone. Don't be too harsh on someone who uses "public static final String", instead of an enum -- perhaps the person has been developing using java 1.4?
I'm debating about posting the test. It could be googled directly. I guess I could post a "different" version.
A version of the test would indeed be helpful, even if it's not the real one. Cheers.
Liked the post a lot. Would be great if the test code is provided here.
Here is a comment that I left on another blogger's espousing of using logic puzzles as a means of interviewing:
Its not that there is no connection at all (between logic puzzles and programming), its that touch logic problems account for 1% (or less) of the cost of programming to the business. Huge portions are due to poor programming practices. So the "doomed dog" poblem relates to dynamic programming. Fine, I agree it is an important concept. What if they can't, under artificial pressure, come up with the solution? They get a zero in the dynamic programming column. In fact there are many, many ways to determine their skillset in dynamic programming, and none of them have to do with logic puzzles.
If you and others like logic puzzles, great. Go for it. It can help sharpen your toolset.
I don't mean any disrespect, but when these kinds of questions get asked, I see it as a diversion at best and an indicator of the lack of understanding on the interviewers part.
Allan, I like your technique. I would also add a drawing board session to test their design skills.
There are two types of questions. "Narrowing" questions, which have a single answer where the candidate closes in on an answer. The other is "Expanding" questions, where the candidate is free to think of many alternatives and expound upon options and weigh different factors.
I definitely favor the latter.
Post a Comment