Live data from Hacker News

Take-home interviews

blog.triplebyte.com

271–280 of 295 posts

Re: Take-home interviews

#271

Seems good, I like the choice. In discussions on this topic I see a lot of: "Programming on the spot is hard, let people program at home"! But then other people say "Why should I program for free at home, my resume clearly shows I am already a skilled programmer. All this will do is cater to young people without families, or those fresh out of school". I am not looking to hire devs right now, but I am thinking about…

> Offer $500 as a 1099 contractor to complete the assignment within the next 2 weeks or so. Just as an aside, I would actually be more willing to undertake this type of interview if you weren't paying me. I don't have any ethical qualms about interviewing while working a full-time engineering job, but I'm not entirely comfortable taking a contracting job under the table. It may be something of a symbolic gesture give…

> Just as an aside, I would actually be more willing to undertake this type of interview if you weren't paying me.

Sure, and I don't think I would force pay you. Would offer you the in person option, or the homework option without pay. Could maybe work it into a signing bonus if you took the job or something? Definitely not looking to put someone into an ethical dilemma, but not wanting to be one of those companies who makes candidates do really long take home interviews and then makes them mad when they don't extend an offer.

Re: Take-home interviews

#272
post #232

Earlier quoted context omitted.

> Offer $500 as a 1099 contractor to complete the assignment within the next 2 weeks or so. Just as an aside, I would actually be more willing to undertake this type of interview if you weren't paying me. I don't have any ethical qualms about interviewing while working a full-time engineering job, but I'm not entirely comfortable taking a contracting job under the table. It may be something of a symbolic gesture give…

Just give candidates the option to specify a charity of their choice to receive the $500 in their stead.

That is a good option too. Either defer it to a signing bonus or a charity of their choice.

Re: Take-home interviews

#273

Seems good, I like the choice. In discussions on this topic I see a lot of: "Programming on the spot is hard, let people program at home"! But then other people say "Why should I program for free at home, my resume clearly shows I am already a skilled programmer. All this will do is cater to young people without families, or those fresh out of school". I am not looking to hire devs right now, but I am thinking about…

$500 is too low - good developers will often charge $200+/hour freelancing, there is little incentive for them to deal with a take home test for that price with all of the time & stress that come with take home tests. A choice is better than no choice though, but too many companies fumble through handling take home tests to make it worthwhile to a quality developer with any sense of value.

True but I am not hiring a freelancer. I don't think anyone spent a few hours interviewing to try and make $500 off me. I am just trying to be considered of their time, and make it clear I am not giving a giant programming assignment to 100 developers and only picking the 1 best, as that stinks for those doing the homework.

If you get to the paid homework step, we are ready to hire you, pending successful homework.

Re: Take-home interviews

#274
post #63

Seems good, I like the choice. In discussions on this topic I see a lot of: "Programming on the spot is hard, let people program at home"! But then other people say "Why should I program for free at home, my resume clearly shows I am already a skilled programmer. All this will do is cater to young people without families, or those fresh out of school". I am not looking to hire devs right now, but I am thinking about…

I like the idea of getting paid $500 or even $1k for a take home test. It's frankly a simple matter of respect. For employers, they're just asking you to do one task, but for employees, talking to 4-6 companies in an interview cycle can easily be 40 hours of interviewing and another 40 hours of work on top of that. I'm at a point in my career where I mostly refuse take home tests because I'm busy and I value my free…

This was my thought as well, take home tests are a good test of your skills, but super annoying when you already have a job + family + hobbies.

Re: Take-home interviews

#275

Earlier quoted context omitted.

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

Also:

* People who have been on a team long enough to learn how things should work but lack the skills to really do the coding.

I phone screened a guy fairly recent who had a very long background (~20 years) in a pretty security-conscious field. He did very well in open-ended design discussions and was able to explain his prior work very well. He couldn't code trivial binary tree operations, though. I can only assume that someone else on his team is carrying most of the coding burden. This guy might be great at a PM-type job (or not, I don't interview for those jobs), but not as a dev.

Re: Take-home interviews

#276
post #231

Earlier quoted context omitted.

I remember when I first got started with git I committed at an absurd frequency. I don't think it's that unreasonable for someone straight out of college to be relatively new to git, and thus do the same thing. I remember later on I wrote a script that listened to git hooks and rebuilt my project on a remote server. I was still testing manually at that time, as we all do in the beginning, which resulted in a large nu…

Well I can't say too much without exposing the problem. But there were about 16 files in total. All of the comparators that were written had multiple tests. (I shot for nearly 100% coverage..although I wasn't going to force stdin emulation, and mock out system.exits) All of the commits that were performed were done in small amounts. (Also, a few were just for transferring work space to other computers) The task in ha…

66 commits sounds perfectly fine for complete unit test coverage, 16 files, etc. Sounds like this was not the sort of person anybody would want to work with if he phrased the question in that condescending way. He'd probably end up being an insane micromanager.

Re: Take-home interviews

#277
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 have yet to meet anyone who is faking it and cannot be cracked in 5-10 minutes of carefully-directed prodding.

Coding is a skill largely separate from other critical dev skills, e.g. design. Someone can legitimately have deep knowledge of, e.g., how to build a 3-tier service architecture without actually being able to code. This isn't "faking it". It's a different skill. You can study database partitioning strategies and learn about the latest and greatest frameworks for writing web pages and APIs without ever writing a single line of code. And sure, you can try to probe deeply enough to expose where their knowledge stops, but you're still not probing for coding skill. There's actually a decent chance that you'll end up probing for trivia which is not a very useful filter. "Oh, you don't don't know the auto-generated C++ class members? You clearly haven't actually worked in C++!" Yeah, right. Anything known broadly-enough known that it's reasonable to assume all coders would know it is broadly-enough known that non-coders could learn it, too.

Even if you could probe deeply enough in conversation to expose that they can't code, you could do the same with a few minutes of actual coding. When someone can't code, it becomes clear pretty quickly when you ask them to code.

Re: Take-home interviews

#278

Earlier quoted context omitted.

I have pseudo-coded on blackboards many times, which is really what a blackboard coding interview should be. If you get a ding for writing .foreach instead of .forEach, that seems a bit picky ;) However I realize I may have a bias as I do ok on most blackboard coding interviews I have done.. maybe been stumped 1 time out of 15 or so in my life? Some of it is a skill, that the more you do the better you get at it, but…

I was asked recently by a big company to code some classes in Python, on paper. They then questioned my indentation, syntax, and case-sensitivity multiple times! A valid question, but paper-code?

Hah that is pretty terrible. In fact, I don't think Python is a very good language to code on paper due to the indentation side of things. Maybe graph paper would help?

Re: Take-home interviews

#279

Earlier quoted context omitted.

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

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

I think this is where my definition of "talk like a professional" may be more strict. I'm interested in understanding, in opinions, in the actual engineering.

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

Having spent most of my career working with PhDs trying to design and implement signal processing and NLP algorithms, I have experienced a lot of that. Given the proper attitude, it is fairly easy to correct coding deficiencies if someone really understands what they are supposed to be doing.

> People that over-engineer simple things

The greater offenders are fairly easy to detect in a directed technical discussion. The lesser offenders are fairly easy to correct in code review, again given the proper attitude, as they are unlikely to be doing things that require major refactoring.

In short, I think I place much more emphasis on engineering as opposed to coding. My experience has been that any coding issues people with good engineering skills and an attitude worth hiring have are quickly and easily corrected. You cannot really understand the engineering of a system without being able to code it. You might not be as efficient as someone else, but you are capable.

Re: Take-home interviews

#280
post #275

Earlier quoted context omitted.

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

Also: * People who have been on a team long enough to learn how things should work but lack the skills to really do the coding. I phone screened a guy fairly recent who had a very long background (~20 years) in a pretty security-conscious field. He did very well in open-ended design discussions and was able to explain his prior work very well. He couldn't code trivial binary tree operations, though. I can only assume…

I feel like there is some detail missing here. What constituted doing "very well" on the open-ended questions? How deep into the engineering did you get? Since you mentioned he "might be great at a PM-type job" it sounds like you didn't go very deep on int.
Post reply on HN