Comment by PragmaticPulp | Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

When I read the title, I thought this was going to be a story about one of those ridiculous take-home tests that requires multiple days of work to complete. Reading the post (and some of the crucial follow up comments), it appears the author spent 2 hours with the environment they provided and gave up:

> Currently, I'm about 2 and a half hours in, trying to get my virtual environment to run the baseline code they provided.

Reading between the lines (and from the comments/follow ups) I think the take-home challenge might be working as designed: Filtering out candidates who are not yet experienced enough to handle the type of work the company does.

The author’s desire to substitute some of their own, different, code samples as evidence of qualification is likely missing the point: Quickly getting the code to run in the provided environment was part of the challenge.

We had a similar problem at a past company where we cast too broad of a net for candidates: When we did no-prep trials of the take-home challenge among team members who hadn’t seen it yet, completion times were all under one hour. When we gave it to loosely-screened candidates, we got several complaints from people who said they were on hour 8 and still couldn’t make a lot of progress.

Tightening up our pre-screening mostly fixed that problem. It’s not good to waste candidate’s time if they’re not going to be qualified.

>>I thought this was going to be a story about one of those ridiculous take-home tests that requires multiple days of work to complete.

Every single take home test I have ever taken. It took multiple days to finish. And even after finishing it, you still don't get the job.

In one place I not only finished the test. Their onsite interview was made up of four more rounds. The first two were about implementing two features on the spot where two of their engineers watched as I wrote the code. And then in the third round they review your code. All onsite. I not only finished the original assignment, added the two features requested and substantiated every single query on code they had in the code review round.

Yet in the last round, they rejected me because I didn't read their employee's favorite paper. And therefore must be a bad programmer. And this is the one of the most famous company in Bangalore which routinely brags about hiring programmers only on the basis of take home tests.

The whole take home test thing is a giant fraud. Don't fall for it. They are not serious about hiring you. Serious people know whom to hire after an hour or two of discussions.

Also contrary to whatever people think about the archetype inefficient programmer who fails at fizzbuzz, most people can actually code. This whole take home test thing is a marketing campaign and generally a way for in house programmers to make themselves feel superior by routinely asking candidates to finish projects in impossible timelines and yet reject them like they are gods.

> This whole take home test thing is a marketing campaign [...]

I mean, not in this case -- in this case they got 3 features implemented for them for free. That's why they did it.

> they rejected me because I didn't read their employee's favorite paper

I wouldn't take that at face value. It probably isn't the real reason. People often hide the real reason for rejecting someone and will use some lame excuse instead.

That doesn't make much sense- if its code, rejection should have come in the earlier rounds. If it was not about code, why make me write it. This is like days worth effort and a working deliverable at the end.

Either way it shows poor judgement on the part of the company.

I don't love at home tests, but they've turned out to be legit opportunities for me in a few cases. Pretty sure one of them not only got me a job but gave the employer a context which likely encouraged them to keep me after a project I was working on didn't go as planned in the first 3 months.

I've also designed at home tests. I tried to keep them under a half-day and invited people to send me something from a portfolio of past work instead if it corresponded. Work samples are good info. Work samples that are time efficient are even better.

Still, I've also had the really negative experience where I was sent tests that seemed poorly conceived or overdemanding and had no idea whether my work was evaluated or if so how. This is how I tend to do things now:

* If I haven't had a serious interview/screen from someone beyond a recruiter I'll do short well-defined tests (< 2 hrs, or about the amount of time one might expect for an early interview). If I'm asked for something longer, I'll ask if we can wait on that until I've spoken with the hiring manager or a prospective teammate and we both feel like things are plausibly promising.

* I ask if anyone internal has completed solutions and what their estimated time spent was. Also how many external applicants have have completed it and what the range of time invested by candidates who "passed."

* I ask if they have an evaluation rubric and if they're willing to share it with me (along with completed solutions) when I'm done, and what they hope applicants would do if at any point they're stuck.

If the answers to these questions seem well-considered and promising (along with other signals about the job), I'll invest in the test. If they seem poorly-considered or worse evasive, I'll think twice or politely pass. Good answers don't guarantee a positive outcome, but they make it more likely it'll be at least productive as an exercise.

> Also contrary to whatever people think about the archetype inefficient programmer who fails at fizzbuzz, most people can actually code.

Only if you mean it in "everyone can type 200 wpm" kind of sense. If most candidates can code in your panels that most likely means recruiters/hm preemptively rejected every candidate that doesn't have years of experience at faang or whatever local equivalent is ;) (source: did 300+ coding interviews)

I think the take-home challenge might be working as designed: Filtering out candidates who are not yet experienced enough to handle the type of work the company does.

What's strange here is that you're coming this conclusion without having actually ... seen a description of the take-home task itself.

By all appearances, you are basically assuming the company was right (and knew what it was doing in designing this "test") from the get-go.

My own observation indicates the opposite: not always, but far too frequently these companies either just don't describe the task properly; haven't checked if the components / targets actually still work with each other; or just plainly overestimate the time it takes to do the steps the first time, out of hubris (the way clients, managers, and developers tend to wildly underestimate the time it takes to do just about anything).

Which allows them to chortle to themselves afterward: "See, all these candidates failed or ghosted us after agreeing to take the test. That must mean it's a good test. And also that we must be awesome, for having such a hard time finding candidates that meet our exacting standards. But with sea of bozos and wannabes out there, what are you gonna do?"

There isn't enough information to conclude much but if you're failing with a take-home assignment setup, there's a chance that you don't have enough experience to find your way through such problems (assuming a mid-career position). So either you can make that up by learning more about that stack and investing more time or just being honest and losing the interview process.

I don't have time to study more for the interview. I'm too busy inventing a new JS framework that I hope to shove down your throat for your next interview. Hope you have the free cycles!

Reply on news.ycombinator.com