We ended up explaining the challenge and giving them access, plus up to two weeks to submit. (We’d always give more time if they asked).
They could do it whenever on their own time, and then we scheduled a 1 hour time block to review their code. Some people took an entire weekend, some people took an hour. Sure people are busy but at least this method also gives them the opportunity to see if they’d like to do the type of work we do, as well.
Overall ended up with really great hires who seemed to enjoy the challenge.
I haven’t done this but I had a fun experience grilling my interviewer on the relevance of the technical interview. My interviewer worked at a company specializing in virtualization technology. The interview was done remote, and this technical interview was the first step.
I was asked to program a mildly challenging problem, the very type of problem you’d see in cracking the coding interview.. mind you I hadn’t done any prep before because my personal stance was that a true technical interview will gauge what I know on the spot, and not what I’ve crammed or pretend to know.
Sooo, it went as you would imagine. I very slowly talked through the solution with my interviewer and while I was able to solve the problem, it took me all of about 30 minutes at which point the interviewer politely told me it wasn’t going to workout and was happy to give me constructive criticism.
His first feedback:
Your problem solving is sound and you’re on the right track, you’re just way too slow. A good candidate solves this first problem in less than 10 minutes and also solves our second problem. You didn’t even get to the second one.
It was at this point I thought, “screw it, nothing else to lose so why not go for the brutal honesty approach.”
Me: how often do you solve a problem like this in your day-to-day?
Him: Oh never, this has nothing to do with the position we’re hiring for.
Me: So why is this part of the interview process?
Him: For the time being, there’s no other way to gauge programming talent in a short period of time.
It was at this point I was happy the interview went the way it did. This company would rather hire worker bees who cram technical challenges as opposed to someone who took the time to slowly think through a problem they hadn’t practiced.
Since then, I built a platform to hire junior and senior talent at my company which emulates a task a junior or senior developer may be given within their first few weeks. The challenge is simple although a bit time consuming. What’s amazing is that although we tailored the challenge for what we thought a good junior developer could handle, it actually has done an excellent job at weeding out senior developers who certainly were not senior by our standards and for the type of work we would expect a junior to be capable of.
Our challenge was to retrieve data on a regular interval from an intentionally buggy API, and visualize the data. Any language or tool was fair game.
Can you believe it? A challenge that actually asks people to do a task similar to what they’ll do on the job?
They could do it whenever on their own time, and then we scheduled a 1 hour time block to review their code. Some people took an entire weekend, some people took an hour. Sure people are busy but at least this method also gives them the opportunity to see if they’d like to do the type of work we do, as well.
Overall ended up with really great hires who seemed to enjoy the challenge.