Take-home interviews are a perfect match for startups - they really reflect actual working conditions. One way or another, you'll be taking home your work every day! :)
Take-home interviews
81–90 of 295 posts
Re: Take-home interviews
#82The problem I find with these is that while solving a problem might take 3 hours, you can spend an essentially unlimited amount of time polishing code - writing comments/javadocs, neatening up the code, writing more unit tests etc. etc.
Re: Take-home interviews
#83I like these great in concept. When I've been between jobs, I've been very happy to participate in them. A couple open questions: 1 - Is it reasonable to expect a 10x programmer whom your are trying to poach to give up so much time? (Or should you give them a $250 Starbucks gift card or something similar for their time?) 2 - Can you really ferret out cheating? I had a grad school classmate who paid someone to do his…
> 2 - Can you really ferret out cheating? I had a grad school classmate who paid someone to do his (non-programming) take-home homework for a job interview, and he got the job. He only lasted 6 or 7 months, but it was enough to be awful for all parties involved. I don't have a great counter-solution other than ask for someone to come in to the office to do the work, and even then you can't tell if they have remote su…
If only we had some sort of take-home exercise for interviewers.
Re: Take-home interviews
#84I 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…
This x100. I hate these interviews as one of the first exercises. More than once over the years I have spent 5+ hours doing a coding exercise for a company only to get a one sentence response, telling me that my "code fell short". If I pressed them further they might say my code was "hard to read" or "not what they were looking for". Vague, unhelpful, and pitiful responses. 0 interaction. No chance for a rebuttal. It…
Unfortunately, a big part of this problem is that companies face serious liability risks if they give useful feedback.
My experience with tech interviews is that they are actually exams, taken under stressful conditions, with none of the courtesies normally extended to a student.
For instance, in college, or grad school, there is a process for taking an exam. There is typically an affiliated study path, you receive feedback on your performance by a set deadline, and at a good university, someone highly competent grades your exam.
In spite of this, people often describe exams like the bar or their medical boards as the most stressful academic experience they've ever had. As programmers, we have to go up to the whiteboard regularly to take a test, or complete a take-home exam and send it off to who knows who, but we often don't know the subject that will be tested, the competence or credentials of our examiners, whether it will reeve a fair assessment, or even any assessment at all (do they just throw the thing in the trash and say "we decided to go in a new direction"? Truly I have no idea.
That's a huge problem, and it is actually outright harming our industry.
Check this article out
http://www.fastcompany.com/3043082/most-creative-people/why-...
This particular article is about hiring women, but I'm absolutely certain that plenty of men are also deterred from pursuing new tech jobs because they can't stomach the idea of another round of technical testing (with none of the factors I listed above that makes it more fair for the examinee), whether that is white boarding data structure or doing take home projects. I think a lot of people may look at this and decide to just enter a different industry altogether, and I really can't blame them.
I'm on a tangent here, but I really think that tech needs to heal itself, and we're a long way form it.
Re: Take-home interviews
#85I like these great in concept. When I've been between jobs, I've been very happy to participate in them. A couple open questions: 1 - Is it reasonable to expect a 10x programmer whom your are trying to poach to give up so much time? (Or should you give them a $250 Starbucks gift card or something similar for their time?) 2 - Can you really ferret out cheating? I had a grad school classmate who paid someone to do his…
> 2 - Can you really ferret out cheating? I had a grad school classmate who paid someone to do his (non-programming) take-home homework for a job interview, and he got the job. He only lasted 6 or 7 months, but it was enough to be awful for all parties involved. I don't have a great counter-solution other than ask for someone to come in to the office to do the work, and even then you can't tell if they have remote su…
I hear you on unskilled interviews.
I guess the challenge in this situation is that the whole reason for take-home work is that introverted interviewees get flustered in person. Won't this happen when the review happens?
This still seems like a better idea than "Tell me about yourself" and "How many golf balls fit in a 747?"
Re: Take-home interviews
#86I like these great in concept. When I've been between jobs, I've been very happy to participate in them. A couple open questions: 1 - Is it reasonable to expect a 10x programmer whom your are trying to poach to give up so much time? (Or should you give them a $250 Starbucks gift card or something similar for their time?) 2 - Can you really ferret out cheating? I had a grad school classmate who paid someone to do his…
If you read the article, the second part of the interview is doing more work on top of the project, but in front of people. I've gone through interviews like that before. Do two steps on a three step kata in front on your own time, and then a 2/3 hour interview to talk about what you wrote, and add the last piece to the kata. Not very easy to fake. Any experienced programmer that is considering a job change will spen…
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.
Re: Take-home interviews
#87This is presented as a weeding out technique but it is actually a negotiation step. This allows the employer to establish precedent that you work off hours from home. This allows the employer to identify candidates that are willing to do whatever it takes for the job. These are the same people that won't do hardball negotiations for salary, employment terms or working conditions. Rather than weeding out the people wh…
My strategy was to tell them something like "First I'm going to interview at all the companies that don't require take home assignments, and then I'll get back to you if I don't have a job by then".
Re: Take-home interviews
#88Earlier quoted context omitted.
1 - We don't expect anyone to give up this much time. I realize that it's a big ask. However, a lot of programmers we've spoken too really want this option. Anyone who does not want to is totally free to go with the (faster) regular interview. Either they let is watch them code for a short time, or they code for a longer time on their own. 2 - I can't say for sure (we're only just launching this), but I hope (and thi…
Out of curiosity, what are the demographics of the people who made these suggestions? Were they employed? Were they very desirable to companies? Were they very undesirable to companies? Did they have financial hardships? College graduates? College dropouts? I think it's important to remember how diverse the hiring pool is, and which voices tend to be the loudest. I would argue that the advice most companies get are f…
Less experienced programmers are definitely over represented in engineers adversely affected by stress. This could be because people get better at interviewing at they gain experience, or because the people who can't perform under interview stress drop out of the profession
Re: Take-home interviews
#89I 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…
"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."
Maybe a tweak would be to only offer take home projects to candidates only after committing to bring them in for an on-site interview, then the interview consists mostly of reviewing the code from the take home.
(Personally, I think I'd still prefer the "coding in person" option.)
Re: Take-home interviews
#90This is great. I especially love that candidates are given a choice, so if they prefer the traditional technical interview they can choose that. Normalizing performance between the two interview types will be challenging, but I think the benefits to be reaped far outweigh the difficulty of the challenges.
Agreed. My reaction was "finally!". I really do not approach software engineering as Performance Art -- and I never write code on white boards when I work. I've been fortunate to have been asked only once to do such a performance in an interview, and my reaction was unfortunately (and unexpectedly) like the candidate they described. In that case I didn't write anything on the board, but instead explained verbally how…
You've got to be a little careful picking out items from their CV, though, especially if you go back far enough. I barely remember anything I did six months ago, and anything one or two years ago I couldn't explain to you in anything more than a really broad overview, despite being neck deep in the code. I've since moved past that, tackled other projects, stuffed my head full of knowledge of other systems (and hobbies), and all that deep technical information on those projects is long, long gone.