|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 3
3. Stick to the job at hand
Coding quiz problems come in all flavors, but don't include questions on your exam just because they sound clever. Broad,
conceptual questions are fine, but if you get specific, make sure that what you're asking actually applies to the position
on offer.
For example, if you're mostly a Java shop, it makes some sense to ask candidates to provide code samples in Java. But don't give candidates a problem in Lisp just to throw them a curveball. Likewise, unless you're working on embedded systems, it doesn't make much sense to grill candidates on which compiler options will produce the smallest object files. If the questions focus on trivia rather than your actual work environment, your test will have as much real-world value as a pub quiz, and you'll end up excluding candidates essentially for no reason.
4. Don't neglect the human element
Problem-solving and coding ability is important, but they're only part of a software developer's job. A successful candidate
must also have the interpersonal and communications skills necessary to conduct the day-to-day business of meeting with stakeholders, gathering requirements, providing progress reports,
and collaborating with other developers.
That's why you should put equal focus on ascertaining candidates' working styles as on their coding skills. Be honest about your organization's workflows, deadlines, and pressures. Ask candidates how they prefer to work and be managed, and encourage them to ask questions about your company and how it operates. Even a candidate who performs exceptionally on programming quizzes might be a bad fit for the position, so always counterbalance test results with less formal interviews.
5. Don't let HR be a barrier
We've all seen those ads for software development jobs that ask for seemingly impossible qualifications: "The candidate must
have 15 years' professional experience in Microsoft .Net." Software development is a highly technical field, and positions
often have complex requirements. Because of this, HR professionals can sometimes do a poor job of screening applications for
programming positions -- for example, vetting candidates based on an alphabet soup of acronyms rather than their actual level
of experience.
Even worse, many HR departments are now using automated systems as the first phase of the hiring process. Before they can submit a résumé, candidates are asked to answer a series of questions on an online form; for example, "How many years of experience do you have with .Net?" Answers that don't fit the predefined profile for a position can effectively blackball a candidate.
These kind of pass-or-fail quizzes are the worst kind of interview exams, and they should be discouraged. Instead, managers responsible for hiring developers should accept that they will need to take a more hands-on role in screening applicants, as time-consuming as that can be.
6. Employment is a two-way street
Finally, always remember that the goal of interviewing is to staff a position, not to put applicants through the wringer for
testing's own sake. Candidates arriving for their first on-site interviews will have as many questions about your company
as you have about them. The interview process should feel like a dialog, not a trial. Don't make it so one-sided and adversarial
that it turns candidates off to working for you. Remember, if they have enough skill and experience to make them attractive
to you, chances are your company isn't their only option.