DEV Community

Discussion on: 10 Hiring Practices That Will Keep Me From Working for You

Collapse
 
tisri profile image
Not my circus, not my monkeys

Whiteboards can be a useful way of seeing if the candidate understands some basic concepts, as long as it doesn't turn into the kind of example you mentioned. Years ago I interviewed with an investment bank and they asked me to sketch a couple of things on a whiteboard that did little more than prove I knew how options worked and how a forward rate agreement was priced. The flipside is the kind of coding test that measures how well I know one very specific aspect of coding - I very nearly walked out of one interview because the interviewer expected me to write a piece of code using a very specific control I wasn't familiar with, as if not knowing that specific control meant I didn't know the language. I even told him straight that if he wanted to know whether I knew that control I could save us both a lot of time and say it wasn't one I'd used much before.

Pay and benefits seems to be a big one. Conventional wisdom seems to be that you don't discuss pay and benefits until the third interview and maybe not even then. Let's be frank, if I'm expecting $150,000+ and you're offering up to $100,000 we might as well both save our time and not bother pursuing this. It benefits neither of us to ace the first interview, come back for another, then discuss salary only to find we're so far apart there's no happy medium.

Contract-to-perm may work for some people so I wouldn't say it's a huge non-starter. It has drawbacks but maybe it's the chance that some people need to prove themselves, especially if they come from a non-traditional background. It potentially makes it easier for someone without an IT degree (or with no degree at all), career changers, the self-taught etc to prove themselves without the employer being on the hook if they turn out not to be as good as everyone thought. Obviously it only works if the company follows through and does upgrade the contract to a permanent job.

The HR pre-screen is a real bane, as is dealing with agencies. That said computerised pattern matching seems like it's more about learning to beat the system than doing anything useful. In a past life I knew a guy who was a really good VB programmer who knew nothing about SAP, at the time SAP was a very in-demand skill. His online resume contained the phrase "I have no experience whatsoever with SAP". Of course the agencies he worked with were always searching for "SAP" so his resume kept coming up again, and again, and again. When they were looking for a VB guy he was the first one they thought of. That got him in the door, and he had the skills to ace an interview from there.

It's always funny when you see an ad for a job that requires more experience of a technology than is possible, or an application claiming more experience than is possible. I still remember getting a resume from a guy with five years of C# experience. That was impressive, given C# had been available for two years at that point. Maybe he was one of the engineers who wrote C# but if that were the case I doubt he'd have been interested in the junior position I was looking to fill.

What always annoyed me the most was when a company wanted applications but then couldn't even do the courtesy of a reply. I get it, you've got lots of applicants for this well-paid job but is it really so much to ask to send a response to people you aren't inviting to interview, or the people you interview who you aren't inviting back?

One key point is that interviews have to work for everyone. If your candidate has a job it's no good to just tell them "I need you here at 10am tomorrow" because it's not necessarily easy to just bunk off work. And when your candidate is there, be aware of their time. If it's an interview over lunch or before work, respect where they need to be. Don't expect them to stay with you for 90 minutes, then get back to work with a vague excuse about meeting a friend for lunch and service being really slow, then having their stomach growling all afternoon because they didn't actually get to eat any lunch at all.

Your comment about cultural fit is a good one. Monoculture can be a very damaging thing especially in a technical field but if someone just isn't going to fit in it can be disruptive. How to balance needing someone to fit in while also bringing their own (perhaps quirky) thought processes to the table, while also doing everything possible to eliminate bias based on irrelevant matters (age, race, gender etc) is potentially tricky. To a large extent it depends on whether the position in question is for little more than a code monkey or an analyst/problem solver.