Do you do custom tests/work for a potential employer before the interview? [closed]

Question

Every shop I've worked at we have followed what I thought was a standard hiring sequence:

1. Solicit resumes
2. Phone screen applicants we are interested in
3. In-person interview
4. In some shops, second in-person interview (just w/ CEO for example)

Most places I apply to follow something along these lines. But some shops want to give me a test or ask me to build something after I send in my resume. They usually say "congratulations, you've made it to stage 2 of our hiring process!" But for all I know they are asking every applicant they get a resume from to do the same thing.

This annoys me because it doesn't scale. If I'm applying for a lot of positions I can't spend all my time doing work that potentially can only land me one job. Plus there's no shared dedication to the process. If we do a 45 minute phone screen, that's 45 minutes the company commits to me and 45 minutes I commit to the company in hopes of a potential match.

Do you guys have a policy regarding these sorts of things?

Answer 1

I think that "The Joel Test: 12 Steps to Better Code" is a widely accepteted criteria for good softwarecompanies . It reqires

 > 11) Do new candidates write code during their interview? 

Answer 2

• You are right in assuming they would be asking every applicant to do the same thing.
• The task generally sent by them are probably common in their day to day development . what they would like to know is if you can do "their kind of" job.
• It shows that they don't really trust whats on the resume.
• It helps evaluate the candidates present circumstances beside his obvious technical ability.
• for instance if he spends enough time to complete the task it tells a lot about his present options or i might be wrong, but dare i say, lack of?
• His Interest in their company.
• Depending on the complexity of the task the time in which he delivers also determines the candidates eagerness or urgency for the job.
• It is up-to you to determine considering the various factors about the company if its worth your time in taking up the task.
• All this considerations apply only in situations where you face such tasks right at the start of the interview process.Generally most companies keep such rounds to the end because they have better filtration process to weed out unsuitable candidates.

Answer 3

Yes, we give a test to all candidates who pass the phone screen. The test is a simple one, build a simple web app in .NET, takes less than an hour for anyone who's spent a year working with .NET web apps. This is an easy way we've found to weed out those who claim 5 years .NET experience yet can't open Visual Studio (yes, more than one candidate could not figure out how to open VS), or unable to do other simple activities. It does take time for me, to answer questions and then review the test, so its not quite all on the candidate. But experience has taught me to not waste time interviewing someone until I know they can do basic things.

Answer 4

We ask all potential employees to write a simple class library and unit test before the in-person or phone interview. We give most people who hand in a CV this test, but we couch this as a "we would like to interview you -- before you arrive, please do this coding assignment and send it to xxxx". Some notes:

1. I would expect the test we give to be under an hour's work to accomplish.
2. We do review the code in depth -- make sure it compiles, make sure the unit tests test what they are suppose to test, check for obvious performance issues, etc. I dare say that we spend almost as much time reviewing each test as the applicant does writing it.
3. It gives us something to talk about during the interview process. We ask questions why they did things one way or another, ask about unit tests, etc. Because we give the applicant our requirements, this also allows us to keep track of how he/she handles vague requirements (you'd be surprised on the number of people who assume the same time zone when handling time comparisons).
4. You'd be surprised on the number of applicants that simply cannot code. Yes, we're probably filtering out a few employees that would work out. But, I would not give a hire/no-hire decision without seeing actual code the applicant has written.
5. I don't trust what is on the applicant's CV. However, I don't trust what they hand in either. Frankly, the assignment can be Google'd and copied from the web. Whether or not we hire is based on a mix of how they answer questions, their prior experience based on their CV, and how they do on the assignment.

When I apply for a new job, I would not be put off by a test if it is obviously to see how I code and if the code is reviewed during the interview.