The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It only takes a minute to sign up.
Sign up to join this community
At our company, i've written an exam that provides relative technical assessment. The test questions range from simple to difficult.
Is it appropriate to provide compulsory technical examination for a technical candidate? If so should it be written or orally executed?
Yes
It provides an additional, objective input to the selection process. And it can save time, because some candidates will just give up and go home.
And although I am not a lawyer, I think it is a good idea to have a standard test given to all candidates. The written test results can help defend against a discrimination complaint from a rejected candidate. On the other hand, evidence goes both ways, so you probably want to seek counsel before creating any discoverable documents.
Write your own test, with long-form answers, rather than using a multiple-guess exam from BrainBench or similar services. A skilled test taker can do well on a multiple-choice exam with no prior knowledge.
I prefer a hands on technical assessment. It is more important to see how the problem was solved than that the problem is solved. I would rather have a "wrong" answer that was achieved through a good method than a "Correct" answer that came from memory.
I'm going to provide two perspectives to this.
The first is that part of my dream job would involve sitting a test. The role has a highly mathematical element and the test is there to ensure basic competencies needed to do the job. This is ok, since a test can show this - can a candidate perform to a strict minimum level.
However, I am also a software engineer, and for these kind of roles I do not think a technical test in an interview is a good idea. For starters, all decent software engineers can pick up any language they so desire and should be able to research and solve problems. That's what you'll be doing on the job and it's hard to write a test that covers those competencies.
Instead, I much prefer an interviewer set me a problem to complete before interview. It shouldn't be too big, but it should show my ability to code out a solution to a problem.
It also reduces the number of people you need to invite to you for assessment, which is an expensive business. It gives you something to talk about in interviews and is somewhat self-selecting in that candidates who are not prepared to put the effort in to complete the task will not even be interviewed.
Finally, this method takes the pressure off the interview and allows you to use this time for assessing interpersonal skills and other "soft" requirements, if you like.
I would shy away from a test. Writing a test that intelligently evaluates a candidate's knowledge, and avoids trivia is hard. And I've heard that some really good developers do poorly on such tests.
What I like to do when interviewing candidates is ask to rate them to rate themselves on a scale of 1-10 on all the relevant technologies they'll be using if hired. Then I take whatever technologies they rated themselves the highest in, and I just chat with them about it, and make sure they have a good understanding.
If they rate highly JavaScript, then I'll ask them about closures, how the this value works, etc. If they rate highly in Entity Framework, I'll ask if they understand the steps needed to avoid superfluous database calls, select N + 1, intelligently abstracting the data layer, and so on.
I've seen it done a couple of different ways - recruiters asking me to go take a BrainBench exam and having to do hands-on exercises at an interview.
IMO, seeing someone code / whiteboard / design something (or on the flip side, having to do that stuff), really says a lot more about the candidates skill set than a resume or cover letter will. I'd rather see how someone thinks and approaches a problem. As a developer, I'm really not interested in how well your resume is written - it just needs to convince me that you can do the job I need done.
I'm interested in seeing how a candidate approaches a problem and thinks on their feet. Yeah, interviews are stressful and lots of people have problems in them, but you can make allowances for that. I don't expect someone to come in and ace the interview - it's hard because I want to hire the top 10% (or 5%) of developers. I want the candidate to walk out of there knowing that they had a hard, but fair interview. I want them to want to come work for us, not just a "yeah, I could work there", but a "man, that would be an awesome place to work".
I've been given an exam in lieu of a phone screen, and I've also been given a short-answer quiz.
A short-answer quiz (about 5-7 questions) is a good idea. It's basically a phone screen but in paper form, and it might save you some time. You can give it to weed out people who don't know anything, or like to make stuff up.
ANY assessment is fine as long as:
Giving someone a test and not exploring the answers with them is pretty often just a waste of time.
