I'm reading this Slashdot article about IT professionals being tested on the interview. There seems to be two minds about this, some people hate it and thing that it's disrespectful, others think it is mandatory. What about you?
I'll be honest, I've never been asked to write code in an interview (as far as I can remember). This is probably because either I did so poorly on the pre-code sections that they didn't even want to bother, or I did so well on the pre-code sections that it was just assumed I could code. One company I worked for started giving coding questions after I had started, but I never had to take it (I probably would have mucked up a few questions).
This is a difficult question to ask. The argument Slashdot puts forward is that companies don't ask other professionals these kinds of questions on the interview, so why should they ask IT professionals? It seems fairly disrespectful, they say. If somebody has several years experience, a degree, certifications, etc. it should be a fairly good indication that they can code.
On the other hand, there are a lot of bad coders out there. Some of them even made it through university. Imagine random guy Joe in high school, with excellent interpersonal skills and a passing interest in computers. He hears one day through some survey that graduates of computer science (or a related discipline that has computer or software in its name) get paid a fair bit more than everybody else. He goes to school to study this stuff, picks a school with a relatively easy program, and squeaks through with 50's. He goes off and works for some smallish company for a while doing simple in-house software, doesn't do it too well but they keep him around anyway because as mentioned before, he's a nice guy. He's now got a few years experience under his belt, plus a shiny degree, which can pad up his resume fairly well (it'd probably look better than mine).
Now Joe goes and applies at a new place, hoping for a higher paycheque. What happens if they don't give him code samples? He could probably get in fairly easily. He's got experience, he's got a degree, and he's a nice guy. What more could you want? Well, Joe can't write a program that swaps the values of two variables. Nor can he write FizzBuzz. Yet he gets the job over some new grad hotshot who went through with A's but has no real work experience.
So this is a perfectly good reason as to why companies would give coding tests during interviews. Do I blame them? Not really. However, it does depend on the coding questions. For the company I mentioned above (which happened to be the first job I got out of university), they give a question on CSS, on how to make it so that a box on a web page can have rounded corners, but be able to expand and fit any amount of text. Pretty easy right? I probably wouldn't have gotten it. My CSS skills when I graduated were sadly lacking - I'm still not incredible with it, makes me wonder why I'm a web programmer. I probably would have given some crap with <img> tags relatively positioned a bit, with some IE specific file somewhere. I didn't know about the whole background-image field. Yet it took about 2 minutes looking at how someone else did it for me to be able to replicate it. Some coding tests, from what I've seen, fail to take into account that people are capable of learning.
This is where the 3-month probation period comes in. I think that this time is good enough for both the company and the employee to see if they are a good fit for one another. If the coder sucks, then the company can let them go after the 3 months. If the company sucks, the coder can leave. It's not perfect, but it is a whole lot better than letting the interview alone decide everything.
Sep 15, 2008
Subscribe to:
Post Comments (Atom)
2 comments:
The 3-month probationary period to evaluate a cadidate only serves it purpose upto a certain point; evaluating whether the candidate cope with the normal responsibilities without underperforming poorly.
However, if the candidate is underperforming, it leaves the person evaluating this candidate at the end of the probationary period with a much tougher decision than they did when interviewing this person. Now they have the guilt of having to make someone jobless, the impact on the team morale (sacking 'frindly joe' who was the 'glue of the team', yet mucked things up). As Joel Spolsky pointed out, it is much harder and costlier to get rid of someone than take the time and effort to recruit the right person. This is why the interview process appears to be so harsh.
But it also should be noted that, this perceived unfairness isn't unique to the IT industry - no one interviews a juggler and not ask them to demonstrate their skills :)
Furthermore - candidates who demonstrate willingness to learn aren't always those with the ability to learn. Evaluating ability is the trickiest part of the interview process, and as fair as one can try to make the process to be, nothing weeds out the wafflers and pretenders like putting them under the spotlight and seeing how they do.
You're right about that.
I think the original Slashdot article was both a lament to being grouped apart from more respected professions, and an attempt to find the silver bullet to make everything easy and fair.
Post a Comment