Hacker News Reader

This sounds way way way worse than a simple test. I think the critical thing is that your online test shouldn't be difficult.

A simple fizz-buzz level test will narrow 700 candidates down to like 100, no need for arbitrary nonsense like linking to github profiles, contributing to open source or typos.

Respectfully disagree, especially in a world where simple tests will be solvable by LLMs/code-assist tools remotely.

* How would you proctor the test to know the candidates aren't cheating?

* How would your test actually test capability to program? (Assuming a legitimate test and not just a blind take-home proving you can code a todo-app...)

* What do you do when your test is leaked online?

* How is your test better than requiring an accredited degree from some institution? (which, for the record, I think is also not a great filter.)

The test is switching the filter from you filtering candidates to the candidates filtering you. Why apply to you when I can apply somewhere else? Interestingly, Canonical keeps coming up as a place to _not_ apply for because their entire process is bonkers: https://news.ycombinator.com/item?id=39750181

I think asking candidates to fill out 18 pages of prose before talking to someone is inhumane.

Fair point about LLMs, but I'm still not sure it matters. Say 20% of applications cheat - what does it matter? They still aren't going to get the job, it just means your filter is slightly less efficient.

> How would you proctor the test to know the candidates aren't cheating?

I wouldn't. I would just add a note "if you cannot pass this test without cheating then continuing the application will be a waste of your time; we will do more tests in real life" (but nicely worded). I don't think candidates want to waste their own time either.

> How would your test actually test capability to program?

I'd probably use leetcode.com but with very easy questions (no dynamic programming!).

If you mean "how would I test good programming taste & architectural design skill?" then that is really hard. Take home problem is probably the best way, but I'd just make it a short one (1 hour max).

> What do you do when your test is leaked online?

Change it I guess. But it doesn't really matter anyway. We're talking about people who can't do FizzBuzz.

> How is your test better than requiring an accredited degree from some institution?

Because most programmers don't have a degree in programming, or even in CS. Do degrees in programming even exist?

On top of this, it's important to consider whether your set of filters is more useful (and moral) than just randomly selecting a subset of candidates.

> The imagination is the limit!

True, but those are pretty bad filters. Why is all that detailed work (x 700) better than getting people to do a test?

Just roll the dice. I refuse to believe that the average recruiting process is better than a fair dice.

The outcome seems to be a dice roll anyways. All these ceremonies just introduce bias.

Put up some requirements, get applications, roll the dice. Qualified, real person with valid credentials? If not, reroll. Can talk to you inperson for 30 minutes without seeming to want to cut your throat? Give offer.

For what its worth, modern recruiting pipelines should be able to automate a good chunk of resume filtering for you if that's what your org values. Being able to only grab applicants that have `Go` listed in their resume, for example, or those who claim to have a degree. That should make a dent in the manual effort. Nevermind that you would still need to review whatever output the "test" is giving you.

I agree with part of what the OP said:

> My take on interviews is that the company must eventually spend as much time as the hired developer in the process

In my opinion, making applicants take a test is creating asymmetrical busy work just so the job-poster can feel that they've selected the "best" candidates (whatever that means). If you legitimately have enough great applicants that you cannot possibly hope to interview them all, then just roll a dice!

> If you legitimately have enough great applicants that you cannot possibly hope to interview them all, then just roll a dice!

How do you know they're all great? You know you have 700 of them. What do you do next? Pick one at random, because you don't want to hire unluckly people?

> * Filter candidates who put objective statements in their resume > * Filter candidates who don't put objective statements in their resume > * Filter candidates who don't have a link to some online portfolio (Github, personal blog, etc.) > * Filter candidates who don't contribute to open source

I can't tell if this post is supposed to be sarcastic or not. I'm assuming so? Because these criteria are horrible compared to what's currently done now. "* Filter candidates who put objective statements in their resume". What in the world is that?

If it is just sarcastic then why even post it? Why not post an actual proposal for a better way to interview?

Its both. I chose some particularly ostentatious examples to drive home you can select for whatever it is you may or may not want without subjecting your applicants to _tests_. I figured the dual-objectives would make that clear.

> * Filter candidates who put objective statements in their resume".

> What in the world is that?

Some people, as well as my early education, recommended to put "objective" statements on your resume stating your literal objective in applying for the role. I'm surprised you haven't heard about them! edit: Personally I dislike them as archaic wastes of space.

So quoting myself

> Why not post an actual proposal for a better way to interview?

And quoting you above:

> you can select for whatever it is you may or may not want...

Yes a person can do anything they want when interviewing candidates. That was never a question. The topic being discussed is what alternative method that gets you great candidates.