Hacker News Reader

Trying to get an objective information to work with is fine. Expecting someone to work for free without any committment / investment from the company is TOXIC.

I have a friend who set the expectations upfront (working from home) and was told it might not be a problem, finished the whole ordeal of take home assignments and technical rounds. The company liked him but he was told WFH is not acceptable (hello Tencent).

I think the point is they're not working for free - they're doing an assessment. If they're asking you to do real production work for free, that's one thing. But giving you an exercise to assess you is something entirely different.

Yeah, what's really strange is realizing that others buy into the instagram resume hype. I'll keep things anonymous to protect the guilty, but one example I know about personally is a somewhat famous Googler in a specific domain, who actually gets cited here once in awhile for his work in said domain. He used to work at a much more backwater company with a friend of mine. He was working on a project for 12 months before leaving the company. My friend was tasked with completing the project, and came in and saw that basically no code was written in those 12 months. I run into these "emperor has no clothes" moments from time to time, but that was an especially momentous one for me.

I'm not sure what the takeaway is supposed to be from this comment, because clearly a Googler is capable of passing Google-difficult coding interviews. If the emperor has no cloths, so to speak, then coding tests don't filter that out either.

IMO, the problem really stems in the types of ways interviewers go about trying to assess skill sets. Rather than assess for the very specific skills that will be needed in order to do the job being applied for, it becomes some random take-home exercise they likely copied from somewhere. I take issue with the assumption that devs are against any kind of skill assessment. They are just against skill assessments that do not reflect the skills they will need to be successful in the job at hand.

In my experience interviewing, a properly designed technical interview exercise can fairly accurately peg an interviewee's skill levels in about an hour, as well as their ability to communicate with the team (taking into account nerves will likely reduce their performance in an interview setting). I think having a take-home exercise could be an option that could be offered, particularly if someone is struggling in an in-person(or video) interview session, or even something that is flexible ahead of time to allow the interviewee to put their best foot forward by choosing the evaluation that best suits their strengths.

I do agree with your point that interviewers need to have an ability to spot "good interviewees" - some people are just really good at interviewing. I don't think that automatically means take-home assignment though, I think having gradually more specific questions to suss skill level out (which you mention, i.e. "better questions") is really important.

You can't control for all edge cases in an interview.

Having an interview process exactly like Google won't give your company Google-like engineers.

Most smaller companies also don't want Google-like engineers, I would posit.

> I've worked on a couple of teams that hired solely on the "strength of the résumé,"

> We realized they were just good interviewers

It sounds like they didn't hire solely on the strength of the résumé, because then wouldn't interview performance be irrelevant? In contrast, there are people with strong résumés who don't interview well, regardless of the interviewing method.

> The two people I know we hired on that basis quickly cycled out (one fired, one quit) because they were pretty terrible.

This is how it should work, I think. Hiring is extremely difficult. Mistakes will be made. The key is to quickly correct those mistakes and move on.

Good luck hiring and then firing incompentent people (and there are many such "programmers") at scale. At least by making interviews hard you're not putting families at risk which you would by hiring people to fire them with pretty high odds.

> you're not putting families at risk which you would by hiring people to fire them with pretty high odds.

I'm not sure what you mean by putting families at risk?

Getting fired from a job when you are providing for a family is a very precarious situation to be in. You're family is put at risk when you are fired.

I was tring to give hawk_ the benefit of the doubt by not assuming that's what was meant, because it seems like a very bizarre concern to me, given that hawk_ was talking about "incompetent people".

Incompetent people put their own families at risk by trying to work in an industry where they're incompetent. It's not the responsibility of employers in that industry to provide for the families of people who can't do the job. It's really a bizarre concern to be worried about the families of fakers. Moreover, how would it be better for the family of a fake for companies to not hire them at all, as opposed to hiring and inevitably firing them? In either case they'll be unemployed ultimately, but at least if they get hired and fired they can pick up some paychecks, so that's actually better for their families, if that's what we care about here.

The quotes on incompetent was missing. If someone's set at a place and proves to be "incompetent" in another setting their family is better off if they never switched the job in the first place. Hiring someone with 5/10+ years of experience for example and firing them after trial is a worse outcome for most people than not having had them make the switch in the first place if it was avoidable.

This is conflating 2 different situations:

(1) Competent programmer who isn't a good fit for a particular job.

(2) Incompetent programmer, the "can't code, can't even write a for loop" bogeyman that seems to scare everyone.

Coding interviews — whiteboarding, take-home projects, and the like — are intended to filter out (2). But they aren't good at filtering out (1).

(1) can always occur. There's not a great way of avoiding that until they actually get on the job. Of course it's unpleasant to fire somehow who doesn't work out, but I don't see how take-home assignments are supposed to help here with (1). Whereas the (2) people shouldn't be in the industry at all, and they're lucky to somehow scam someone into giving them a job, but the industry should not be financially supporting scammers or their families.

I'm personally not convinced that (2) is as big a group as many people believe it is.