Slashdot Mirror
Programming Job Skills Test?
eclecticgeek asks: "I've recently finished a CS/SD degree at uni and the interviews are starting to come thick and fast. I've yet to have a skills test for any of them, and it's only a matter of time before I do. I'm hoping to do one this week and I will get the choice of language. The position is quite broad and they're more after competent programmers in general, rather than any one specific language. So I'm wondering, have you done a developer skills test? What type of things did you get asked?"
You can't prepare for the kind of BS that can get thrown at you in skills tests. I've seen things that you'd have to have the C++ Standard memorized to know, quirky product specific things they want you to know, and one place that set me down with a bug report and a development box with their code on it and wanted to see how I'd approach it...
I ususally ask the most important question first: where can I see your code on-line--which in practice often means: which free software project have you contributed to? It's better than a test because I can see some Real World(TM) problem solving skills, read the mailing lists archives to see interpersonal communication skills, ask other developers, etc. Why is it more important than tests? Because that way I can see how the future code is going to look. Academic questions and tests are good for students, but the Real World(TM) is very different. In the Real World(TM) understanding CPAN and APT is more important than understanding the Turing Machine, even if the latter is otherwise much more important than the former for any serious scientist. Today usually in every group of candidates there are at least few who have their code to show, so it's pointless to waste time on those who don't. Also, it seems important to award those who are productive and useful to the humanity at large, to punish and motivate those who aren't, and to tell the Big Boss(TM) "I told you, embracing the open source paradigm is profitable and good for the economy. Why not be more proactive from the hiring perspective and always demand appropriate portfolio up front?" This is just a common sense. For example, hiring a Debian developer you can expect that he will be able to package his software and install it properly on all of the systems instead of cluttering the filesystem with junk and making the servers expensive to migrate. Similarly, hiring a CPAN author you can expect that he will know how to use standard Perl modules instead of wasting his time and your money on reinventing the wheel and writing one big-arse slow-as-hell monolithic stand-alone CGI script when a nice hierarchy of mod_perl modules would work like a charm. I could go on and on forever, but I guess you get the point already. I never buy a cat in the bag. Neither should anyone else. This is not to say that free software and open source is "better" than its proprietary counterpart, but it surely is more visible.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
If I was a perl-head, and that was my reference material (which it would be), I'd have known the answer in an interview. Especially if I had just started learning perl. (I know some perl, but not enough to actually read up on it. C and C++ interest me enough that I consider reading technical documentation about them "fun").
Heck, that was my guess as to what it was (I knew it had to be one of a handful of concepts: pattern matching, a section describing the difference between scalar and associative context, or the first section that mentioned CPAN in that likelyhood order). Pattern Matching is what perl was invented for if I remember my history correctly. That page wasn't chosen at random by the questioner, it was chosen for a specific reason. They didn't pick page 12, they didn't pick page 275. They picked the page that had documentation about the essense of what Perl is, and a page that would likely be referred to early and often.
When we interview people, we have questions of that nature (not insane questions, but questions that we don't expect anyone to answer correctly, but if you do we feel that you can easily be assimilated).
Kirby
Are you applying for a software "design" position?
I should hope he isn't considering he is fresh out of college...
You should get a blank stare. "Typically two tabs in" is another reasonable response.
Sorry, but when you're testing the knowledge of the candidate, your knowledge is being tested too. The worst developers I've had to share code with haven't known what a "function signature" was, and I figure that's a pretty good rule of thumb.
--Matthew
These functions are usually documented in man pages.
Stick Men
surely the clue is the phrase 'thousands of miles from *nowhere*'
I'd just walk to the local shop, seeing as there's thousands of miles of somewhere between me and nowhere.
That's pretty much what I thought too. If being given this upon an interviw my first thought would be how this relates tomy job, reading specifications for clear detail, ie unambigious, and caught this as something that could be interperated in more than one way and ask to clarify that I am not indeed in the middle of somewhere.
When clarified I would then pursure to come up with some fantastic, amazing, impossible method of surviving in nowhere (somewhere?) until I could be rescued.
And as a side note, if I did come upon that set of circumstances and was not ever going to be rescued, I wouldn't think that would be such a bad life considering you can survive, etc. I htikn I would do alright as I've done "rough" things before, but I also believe some kind of nature and instinct would really kick in.
It would be a challange I guess, but I definitly would not try and build a raft home if I had to go 1000 or so miles. Hell, I would even try to start brewing my own beer and see if I could make a paper and use the volcano ash as a writing material. Beer is way more important though.
"If you are a dreamer, a wisher, a liar, A hope-er, a pray-er, a magic bean buyer
I've interviewed at places that did have programming skills tests, and those that did not. When I've been in the hiring role, I've occasionally used them. Some people believe they are a good impartial way to evaluate skills. Others believe you can gain the same info by talking to a person informally.
The big thing to remember is that the test should be "shades of grey" rather than "black or white". If you're not sure about an answer, but you can explain why you made that choice, it's better than leaving them with a yes/no answer.
I've seen good tests, with language specific questions (without being syntax nits) like 'What interfaces or classes would you need to extend to implement a J2EE EJB service?' and general questions like 'Describe 2 Gang of Four patterns and where you'd use them?' (Note, you get more points if you admit you don't know which patterns are in GOF than if you guess incorrectly).
I've seen bad tests, like when I was asked to implement a linked list in C. My response of "I wouldn't, I'd use STL", was badly received. Eventually, I got from them that they wanted to see that I could identify boundary conditions and likely places to mess up the pointer manipulations.
The worst are the downright ugly tests. At my previous job, HR asked some engineers why none of the candidates were passing the multiple choice programming exam they were given. It turns out that a third of the "answers" on the key were wrong, and another third were ambiguous because of the wording of the question (ie, both A and C could be argued to be correct).
To sum things up, expect questions related to the skills required for the job, questions related to the skills you've listed on your resume, and questions about general theory and good practices. Often you can get partial credit for a wrong answer if you explain yourself. Always be honest rather than improvising an answer that you don't know. And you can always ask to discuss any questions you get incorrect, so you can explain your thought processes.