The latest trend for tech interviews: Days of unpaid homework • Hacker News Board

Re: The latest trend for tech interviews: Days of unpaid homework

#381

Post by commandlinefan » Thu, Apr 19, 2018, 5:45 PM UTC

learc83 wrote: post #183

nicolashahn wrote: post #103

Earlier quoted context omitted.

The problem is, there are people with those degrees who still can't even code fizzbuzz.

I question that bit of common knowledge. I went to a large state school for undergrad and tutored people regularly. By senior year, even the bottom performing students wouldn't have had a problem with fizzbuzz or similar screening problems. We regularly had coding problems much harder than that on tests. Unless there were other factors involved like maybe the pressure caused by the weirdly adversarial hazing process…

Yeah, I'd really like to know what colleges these people are coming out of - if they're real colleges and not just paper diploma mills, I'd have to question their accreditation. I didn't go to MIT - I went to a tier-3 (or 4...) school and you couldn't have graduated, with any GPA no matter how low, without having produced dozens of working programming assignments, many much more difficult than any take-home work assignment.

Re: The latest trend for tech interviews: Days of unpaid homework

#382

Post by tachudda » Thu, Apr 19, 2018, 5:47 PM UTC

speby wrote: post #218

Our industry's hiring practices are absolutely obnoxious. In an ideal world, you could trust someone's resume. e.g. "I've written large production programs in C." Ok, great, so then clearly this person knows C so there should be no need to dissect code or run them thru some linked list algorithm and see if they know how to use pointers correctly. Yet, we do. Ok, then what about open source contributions (if they have…

I'm curious if theres an industry that you think has figured out hiring, at least from a lying on resume standpoint I'm not sure which that would be.

Re: The latest trend for tech interviews: Days of unpaid homework

#383

Post by mazelife » Thu, Apr 19, 2018, 5:47 PM UTC

A while back our company switched to the "homework" format for evaluating software engineering proficiency because we felt like it took a lot of stress off of candidates to write code in an unfamiliar environment (or worse, on a whiteboard). And I feel like it's worked out really well. But we have pretty strict criteria for any homework problem: it needs to be a simplified/toy version of something we'd actually ask the person to do if hired, and it needs to be something that a qualified candidate could easily complete in an hour.

The code itself is, of course, valuable for helping us to evaluate, but honestly some of the best signals we get come from the open-ended discussion that results from us talking with the candidate about their code when they are done: "imagine this file you're processing is 100TB instead of 100kb? Would you change anything?" or "What if this clean data you've been given to work with had this or that issue, what might you do?"

My only point of disagreement with this article is that it seems to assume that a homework problem has to be really time-consuming or burdensome, but there's no reason that has to be the case. To me employers who are asking candidates to spend hours or days on homework are of a piece with ones who ask people to solve tricky, unrepresentative computer science problems on a whiteboard: they reveal that they don't really know how to interview people and they don't have much respect for their candidates.

Re: The latest trend for tech interviews: Days of unpaid homework

#384

Post by tboyd47 » Thu, Apr 19, 2018, 5:47 PM UTC

adreamingsoul wrote: post #354

monocasa wrote: post #250

Earlier quoted context omitted.

I used to hate it, but have now performed enough interviews of supposedly senior devs with decades of experience. I've literally seen someone who did firmware for the space shuttle grind for 45 minutes on fizz buzz without making progress. Like, I'd they struggle for ten minutes or so, I take a step back and say "Ok, screw syntax, let's just vaguely talk about what needs to happen and mock up some pseudo code.". Even…

Check your premise. It sounds to me that an assumption is being made because they didnt meet the expectations within a fixed time period. The danger with this is that this is not a real world scenerio of how two people would approach a task or problem. It’s also important to recognize that everyone is different with regards to how they process information. Stress has a real biological effect on how the brain processe…

Solving a problem within a fixed time period is the best real world scenario for programmers. No project has an unlimited budget, so no one gets unlimited time in the real world.

Re: The latest trend for tech interviews: Days of unpaid homework

#385

Post by hitekker » Thu, Apr 19, 2018, 5:47 PM UTC

I once interviewed with a startup that disguised their technical-onboarding as the last step of the interview process.

Learn three different frameworks, unlisted in the job description, and extend a github repo, suspiciously similar to their production codebase.

That they insisted what was easily a 10-hour assignment could be done in 30 minutes "if you're already familiar", made it seem like they were offloading the learning-on-the-job to before-getting-an-offer.

Cunning, but ultimately a sign not to sign.

Re: The latest trend for tech interviews: Days of unpaid homework

#386

Post by aje403 » Thu, Apr 19, 2018, 5:49 PM UTC

trowawee wrote: post #365

tytytytytytytyt wrote: post #360

Earlier quoted context omitted.

So hire everyone who can't function during the interview?

I know several really, really good programmers with pretty intense anxiety. Automatically ruling them out because of a poorly-formatted interview process would be a big mistake.

So basically hire the guy who, if you tap on his cubicle, will have a heart attack and sue your company? If you hire a pretty girl too, does he forget how to speak english? Why not just hire someone who doesn't have panic attacks too bad to code fizz buzz instead?

Re: The latest trend for tech interviews: Days of unpaid homework

#387

Post by xor1 » Thu, Apr 19, 2018, 5:50 PM UTC

trowawee wrote: post #365

tytytytytytytyt wrote: post #360

Earlier quoted context omitted.

So hire everyone who can't function during the interview?

I know several really, really good programmers with pretty intense anxiety. Automatically ruling them out because of a poorly-formatted interview process would be a big mistake.

What is working with them like?

Re: The latest trend for tech interviews: Days of unpaid homework

#388

Post by psyc » Thu, Apr 19, 2018, 5:50 PM UTC

monocasa wrote: post #250

speby wrote: post #218

Our industry's hiring practices are absolutely obnoxious. In an ideal world, you could trust someone's resume. e.g. "I've written large production programs in C." Ok, great, so then clearly this person knows C so there should be no need to dissect code or run them thru some linked list algorithm and see if they know how to use pointers correctly. Yet, we do. Ok, then what about open source contributions (if they have…

I used to hate it, but have now performed enough interviews of supposedly senior devs with decades of experience. I've literally seen someone who did firmware for the space shuttle grind for 45 minutes on fizz buzz without making progress. Like, I'd they struggle for ten minutes or so, I take a step back and say "Ok, screw syntax, let's just vaguely talk about what needs to happen and mock up some pseudo code.". Even…

Perhaps it's because you insist on testing their ability to live code on the spot as a performance piece, and misinterpreting that as testing their ability to code. If you're turning down someone who wrote space shuttle firmware, because they "can't do fizzbuzz", then you are administering a terrible test and getting a false negative.

I have 20 years of industry experience. Everything on my resume is the truth. I've worked on serious code, for serious projects, at serious companies. At work, my performance reviews have been stellar.

When I do live coding interviews, I'm being tested with tasks that are utterly remedial relative to what I've done professionally over long periods of time. Yet I flub these remedial tasks. It could be because I'm nervous. Could be because the interviewer keeps interrupting me mid-line, so I can't think. Could be they are too terse, and I can't drag enough information out of them. Could be the problem is slightly more complex than I can accomplish under any circumstances in a live performance, but that I could complete correctly in a closed room.

These interviews are degrading, disrespectful, and they tell lies to the misguided interviewer. What do they think they're testing the candidate for? Why does it matter whether you can code something remedial, live? Is live performance part of the job function? Do other professions do this? We should end this practice.

Re: The latest trend for tech interviews: Days of unpaid homework

#389

Post by resolaibohp » Thu, Apr 19, 2018, 5:50 PM UTC

monocasa wrote: post #250

speby wrote: post #218

Our industry's hiring practices are absolutely obnoxious. In an ideal world, you could trust someone's resume. e.g. "I've written large production programs in C." Ok, great, so then clearly this person knows C so there should be no need to dissect code or run them thru some linked list algorithm and see if they know how to use pointers correctly. Yet, we do. Ok, then what about open source contributions (if they have…

I used to hate it, but have now performed enough interviews of supposedly senior devs with decades of experience. I've literally seen someone who did firmware for the space shuttle grind for 45 minutes on fizz buzz without making progress. Like, I'd they struggle for ten minutes or so, I take a step back and say "Ok, screw syntax, let's just vaguely talk about what needs to happen and mock up some pseudo code.". Even…

In my experience, candidates who have experience in dev work but could not pass our interview tests always end up in a dev role somewhere else shortly afterwards. Even some of them go on to find much more success.

Either there are a lot of companies which employ unskilled developers who cannot even code fizzbuzz, or interviewing is not a great way to understand specific types of people.

Re: The latest trend for tech interviews: Days of unpaid homework

#390

Post by mywittyname » Thu, Apr 19, 2018, 5:50 PM UTC

newobj wrote: post #338

mywittyname wrote: post #328

Earlier quoted context omitted.

Personally, I think it's fine to expect employers to verify a candidates skills. But they should also limit their verification to the minimum amount necessary. People are just arguing where that line should be drawn. Whether it's hours, days, or months of verification. Some careers do require months of unpaid internships in order to get jobs. And it's not because it takes months to verify a person's ability, but beca…

It's wrong if the company benefits in any way from your interview/probationary period. (Probationary periods are just wrong period IMHO.) Interviewing is a huge burden to most companies, so if your interview questions are entirely synthetic, it's ONLY a cost to the company to interview you, which they should naturally want to minimize on their own. But you know what's even more expensive than interviewing? Dealing wi…

You're not refuting my point though. I agree they should do what they can to ensure they get a good hire, but I also thing they should do the minimum amount necessary to do such.

I've worked on many great teams whose interview process was little more than asking intelligent, pointed questions about previous work experience. Of course, this puts the onus on the interviewer to know what they are doing.

I personally keep a list of elementary questions about various technologies for interviewing. So when someone says they've worked with ElasticSearch or Python, I ask them how to do a few rudimentary tasks in a few of them and can pretty quickly tell how much they've been fibbing.

I've had companies both accept and reject my hiring recommendations, and every person that's been hired despite my objection has been poor quality. So I know at least anecdotally that it's a viable strategy and it only takes ~30 minutes per person.