Software developers huh! What other role requires you to complete an exam to be considered for a job (or even just an interview). Moreover a 4-8 hour exam with no syllabus. No 'past papers' etc. I think this should stop. In it's place, developers can have a pet open-source project, which they submit with their application. The point is that the same project can be submitted for a hundred applications if needed, savin…
FWIW most of the other high-payed jobs have some kind of entrance barrier too, usually in the form of having absolved a Univerity-level course and passed the exams.
Anybody can legally claim to be a programmer, so it makes sense for the companies to do some basic checking that a University would have done for them in other cases.
Won't the same programmer who got flustered in front of a white board also get flustered explaining the code? I'm being the devils advocate here, trying to hone in on the best way to do this. I still think work products are a much better predictor than most any other interviewing technique.
Not necessarily, they are quite different forms of communication. Coming up with something that works, versus explaining why it works or why you did it that way after the fact. I think it's the "thinking out loud" part before you have a solution, that can fluster a lot of introverts.
for some it's not about introversion/extroversion but simply the fact that whatever part of their brain deals with speech is the same part that deals with thinking through those kinds of problems, so they can't do both at the same time as a matter of physics.
this is to put it precisely. the reality is much messier and varied. the point is, people's brains are not wired the same. and what this means, to make a long story short, is that these interviews are not comparing apples to oranges... not even close.
Here's the best approach I've seen yet to the take home interview (and interviewing software engineering candidates in general). Here's a git repo, a problem statement and a slack channel to ask questions. You can use any tools you like and spend as much time as you like on the project for the next week. ---- Employer's perspective: You get to see some code, see how they approach a problem, see how they use their too…
I really like the idea of adding a Slack channel to the problem statement. I always have questions, and channeling them through a recruiter via email is a pain.
A lot of take home problems are very unrealistic, so it's difficult to make the trade-offs that you'd normally make when trying to ship software. Being able to ask someone on the team what their intentions are would be super helpful.
My pet peeve is front-end tests that ask you to write maintainable code, but you're not allowed to use any libraries. So instead you have to create your own tiny MVC/templating/helper libraries just for the project - but obviously they won't be as good as something you've spent more than 4 hours on.
I'm not particularly a fan of take-home tests. But comparing that to mumbling at a white-board, while a software engineer is pretending to be an expert psychologist at analysing your ~train of thought~, and unfortunately, more often than not, someone in the board is only paying attention at how much of an WASP male you are or pass by it, where you need to do a task that you only repeat at interviews for a job that will not require that...compared to that, give me take home interviews any day of my life. Yes they are free work, but at least they are free work related to actual work. Live coding in the whiteboard performances are not part of the work. And the stress argument (that programmers must be able to deliver under stress) there are categories of stress, social anxiety of a live performance is not the stress we deal at our works. Sometimes I do good whiteboard coding interviews, sometimes I do bad whiteboard coding interviews, none of the situations I felt the merit was of the code or my knowledge of the subject, it is not a proof of how well a programmer does his job, is a somewhat related way of knowing if somebody knows who to code something and if he does not feel too nervous to code on a whiteboard instead of a computer to a bunch of strangers testing him. If you add that to the fact that some interviewers like be to randomly arrogant, you're missing some really nice but perhaps shy coders.
Software developers huh! What other role requires you to complete an exam to be considered for a job (or even just an interview). Moreover a 4-8 hour exam with no syllabus. No 'past papers' etc. I think this should stop. In it's place, developers can have a pet open-source project, which they submit with their application. The point is that the same project can be submitted for a hundred applications if needed, savin…
Software devs have extremely low social status, despite pretty good pay. Honestly I'm glad they don't watch "Survivor" and make us eat bugs or do weird obstacle courses. Seriously. You treat people like dirt, they're gonna resent it and complain on HN and some Stockholm Syndrome victims will back up the abusers. Another example of the low social status is those horrible open offices, like a call center. Ugh. Another…
> Another example of the low social status is those horrible open offices, like a call center. Ugh.
So, where you work software devs are in an open-plan space and other roles have their own office?
I thought Gayle Laakman McDowell, who wrote "Cracking the Coding Interview", wrote a good article about the problems of take-home interviews. http://www.gayle.com/blog/2013/09/18/companies-who-give-cand... At the core of the problem is that this approach can be used to burn a lot of a candidate's time without an equivalent investment from the company. I've mentioned this before - I applied (maybe 5 years ago) to a co…
I actually did a similar thing as an ops guy (debugging systems as described in some questions) and really liked the concept. On the other hand I work on mathematical riddles for fun so maybe I'm the core target for those.
It doesn't replace face to face interviews but I can see it as a good example of "how would face this real life situation you would encounter if you got the job?"
The best take-home interview I ever did had a time-limit. And of course, I panicked when getting close to that limit, and tried my best to tidy up my solution but didn't really manage. Then a pop-up appeared asking "Would you like another 5 minutes?" That was just enough time to calm down, tidy up sufficiently, and submit clean code. It seemed like a good middle ground to me.
The only time I've been given one there was a time limit as it was fairly strict. Frankly I'd have preferred an untimed version but I can see why people would disagree with that.
"I can see why people would disagree with that."
Yeah, I can see why too, since almost all software is written with a literal ticking time bomb ready to go off if you don't finish it within a certain minute.
This is, of course, sarcasm. Timed programming interview tests are fucking dumb.
I mean, if an employer gives someone a take home test that they expect to take 3 hours and they give them a week to do it, that's reasonable if technically "timed"; but if an employer gives someone a take home test that they expect to take 3 hours and they actually give them 3 hours to do it, that employer sucks at hiring programmers. I won't even bother debating this with the inevitable person who chimes in to rationalize why they do this, because as far as I'm concerned it is a "the sky is blue" statement and any time debating it with people who disagree with this position is completely wasted.
Agreed (and see the linked comment please): If it's not a replacement for whiteboard bullshit, then GTFO. That's insane and maybe 'the worst'. But it's important to remember that a take home exercise cannot fully replace an interview. It can replace the coding part, the whiteboard "and now we ask useless trivia questions" part. But there's no way for this work to replace the "would you fit the team" interview. Others…
There is a reason that nobody filters by social first. One of the biggest challenges in hiring is that it takes a ton of time to go through many bad candidates before you see any good ones. And time is the one thing you don't have. You're hiring because you don't have enough resources to do the work you already have. Therefore the name of the game is efficiently rejecting candidates while using up the least amount of…
And that seems fair.
Why is it only the employee that is expected to take up time? At the end of the day there is likely to be more than one applicant, so your spending 3 hours of your time for 50% chance at best.