Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Take-home interviews

blog.triplebyte.com

Post reply on HN
Print view View original

261–270 of 295 posts

Re: Take-home interviews

#261

Post by spacecowboy_lon »

robspychala wrote: post #106

From the employees' perspective: Take home tests are the worst. Company says take home test will take 3 hours to complete. They never do. Schedule 2x or 3x the estimate. Especially if you want to impress the reviewer. You send it over, then the company says no or yes, only to move to new stage. In the worst case you ruined your weekend and received a no. But the company just took 10 minutes to arbitrarily reject your…

Another problem is that its not a zero sum game candidates are applying to multiple potential employers.

Forcing you to spend most of a day on an application means that good candidates will just not wast time applying for these sorts of jobs.

An in the uk to get befits you have to provide evidence of applying for x no of jobs per week so wasting 2 days on a single application is out

Re: Take-home interviews

#262

Post by collyw »

jpeterson wrote: post #64
hanlec wrote: post #7

As many other parts of an interview, I've always found the blackboard coding session extremely strange. When was the last time you coded in TextEdit with no docs around, no time to think, standing up, and being watched over the shoulder?

In 15 years as a software engineer at companies large and small, I have never seen anyone code on a whiteboard (outside of interviews, anyway), nor have I.

I usually get a pen and paper out if I have something algorithmic to work out.

Re: Take-home interviews

#263

Post by AlwaysRock »

Tech recruiter here: I have seen so many companies that lose out on good developers because they ask them to do a take home test.

Obviously you want to vet the person technically but you should be able to do that through talking with them. Most developers put off take home tests even if they are excited about the company and by the time they do it they already have finals/offers from other companies.

Re: Take-home interviews

#264

Post by jghn »

georgemcbay wrote: post #248
jghn wrote: post #204

Earlier quoted context omitted.

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 r…

One thing you're missing though is that a time limit allows for a controlled variable when you're comparing candidates.

The test I was referring to I'm almost certain was not intended to be completed in the time allowed. I've used it myself for in person interviews (not take home) and give candidates 3x the time I was given, few of them actually finish it completely. While it just made me feel like an abject failure at the time now I realize a big part of what was being tested was given limited time what bits I focused on. In fact that's exactly what I tell candidates who I give it to.

Re: Take-home interviews

#265

Post by geebee »

ammon wrote: post #55
geebee wrote: post #46

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…

This only applies if the take-home interview is obligatory. I agree that obligatory take-home interviews are unfair (I feel the same about trial periods). They work (they're probably more accurate than a standard interview), but they take too much time from the applicant (and will thus scare away many of the best people). As an option, however, I totally disagree. There's a significant percentage of good programmers…

You know, while I agree that these problems are mitigated somewhat by making the exam optional, I don't think this alone solves all the problems associated with this approach. I still think that asking candidates to spend, say, 5-7 hours on something is a big deal, even if you give them a choice to take a different path.

I'm not inherently opposed to technical tests, either in person or take home exams. I believe that many exam-based institutions adhere to a code (probably unwritten) that grants certain rights to the examinee. Think about exams in college, where stakes can actually be quite high.

Think about exams at a university. Typically the subject matter and nature of exam questions is available in advance. The grader is highly competent in the field. An associated study path is available for the exam. The exam will be graded and scored, and those scores will be communicated to the student within a set time frame. Feedback will be provided to the student. The exam is part of achieving a lasting credential, such as credit for a course on a transcript.

None of these things exist in technical exams, and in many ways, this increases the stress. Merely making an exam "optional" doesn't erase all these problems. I think this is the core problem with technical exams, they contain all of the stress for the student, but have none of those rights that I believe exist in universities and other exam-based institutions for a good reason.

Re: Take-home interviews

#266

Post by nsfyn55 »

darklajid wrote: post #180
nsfyn55 wrote: post #170

Earlier quoted context omitted.

Oh as a number of people have indicated its bad for the company because the candidate can work with someone else and produce a glowing submission. I have helped a number of people do these some that have gotten the job. its bad for the interviewee. They may spend 10-15 hours on this and get rejected for no reason at all. Do you think the person reviewing the submission is putting multiple hours into it. Doubtful. If…

If you were able to explain your 'cheated' solution to someone and they could reliably cheat the interviewer, I'd say you .. taught them. GJ! The interviewee (the vowel count makes me dizzy) can choose what he/she prefers. So that argument is weird. Maybe (if that's your point) it might be beneficial to go for the face to face interview, for direct feedback? But .. some people just _cannot_ do that. You're not talkin…

I think you are missing the point. If you are ok with a "Cheated" response then you are really hiring a candidate based on their network of experts. An equally or more qualified candidate could submit a less stellar answer only because their dad isn't an emeritus chair at a University.

Re: Take-home interviews

#267

Post by hharnisch »

mostlystatic wrote: post #243
hharnisch wrote: post #225

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…

Unless the task was to write an MVC or helper library I'd be concerned the candidate wasn't using a library of some sort. It's really interesting getting a sense of where someone spent their time on a project - asking the candidate that question has been the turning point in the discussion because it a.) tells you if they actually wrote the code and b.) gives you a closeup view on how the person thinks

Re: Take-home interviews

#268

Post by francoisblavoet »

lucasnemeth wrote: post #244

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 wi…

This is why we use Take-Home tests here at deezer. The part we don't have got right yet is how to manage the length of such an exercise. Finding a problem where you have to both demonstrate how you handle several common issues and that is not too long is pretty hard.

Re: Take-home interviews

#269

Post by brianwawok »

vonmoltke wrote: post #239
dpark wrote: post #103

Earlier quoted context omitted.

> Sit me down and talk about technology for ~thirty minutes. This is an efficient way to hire a team of good bullshitters. I've interviewed people who did extremely well when we were "talking like professionals" but were unable to do even very simple coding problems. My bar for coding is really not that high. I don't expect perfect syntax. I don't pick the language. I don't expect "the one answer". I expect people to…

I disagree. I have yet to meet anyone who is faking it and cannot be cracked in 5-10 minutes of carefully-directed prodding. In fact, I don't see how it is possible to do extremely well on the "talk like a professional" part and not be able to write basic programs, unless you and I have very different concepts of what "talk like a professional" means.

I worked with a team of these before. You can rule our certain types of people with tech questions (i.e. never coded before, only coded hacked, etc.). You cannot rule out

* People who read a lot of blogs so know the lingo, but never code

* People who get the theory but can't actually implement something that works without bugs

* People that over-engineer simple things

Re: Take-home interviews

#270

Post by brianwawok »

SomeCallMeTim wrote: post #133
alain94040 wrote: post #128

Earlier quoted context omitted.

> Offer $500 as a 1099 contractor to complete the assignment within the next 2 weeks or so. I like this, not for the money, but because it guarantees that the company is not giving this assignment to 100 different candidates ($500 x 100 is getting prohibitive for a hiring budget). I'm more willing to put the effort if I know I'm one of the "finalists" for the position.

Agreed that it's a positive thing to actually pay people for nontrivial amounts of work. Downside is that, as a company paying someone to accomplish a task, I'd want to give a different task to each applicant, so that if they do a good job, it provides value to the company. And this is a problem because rarely are two programming problems exactly as difficult as each other, so the test isn't normalized. Interviewing…

I mean, a bad hire is going to cost me thousands of dollars - if not tens of thousands of dollars. $500 is pretty cheap to figure that out up front on a candidate I am otherwise ready to hire. I am not going to do this to 100 people and pick the best, I am going to do it for someone that in every other way is a good to hire dev.

I don't think I would give out the same work to multiple people, let them put it into production on their first day and get the pride going ;)

Post reply on HN