Well gosh, what a good problem to have. So many good options that still respect people's times. You get to write a process that selects for the things you want to select for!
Let's assume these are 700 _qualified_ applicants and its for a programming role. I.e. their resumes and applications have passed the most basic of filters of "claims they can do a similar job" and "is probably a real person".
How about...
* Filter candidates if they have typos in their resumes
* Filter candidates who don't explicitly state that they leverage your tech stack
* Filter candidates who excessively job hop
* Filter candidates who have below some minimum of professional experience
* Filter candidates who live far from the workplace
* Filter candidates, for a remote role, who live in HCOL area
* 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
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?
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.
> 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.
Simply skimming their resume would probably weed out 50% of that. A better way is to have a few simple questions on the application, like "Where do you see your career in 5 years", "We use Django here, what are some things you don't like about it", etc. With that, just "skimming" will weed out 90-95%. That said, now that everyone will just pipe that to chatGPT, not so sure how any private interview questions or projects are going to work out.........
Let's assume these are 700 _qualified_ applicants and its for a programming role. I.e. their resumes and applications have passed the most basic of filters of "claims they can do a similar job" and "is probably a real person".
How about... * Filter candidates if they have typos in their resumes
* Filter candidates who don't explicitly state that they leverage your tech stack
* Filter candidates who excessively job hop
* Filter candidates who have below some minimum of professional experience
* Filter candidates who live far from the workplace
* Filter candidates, for a remote role, who live in HCOL area
* 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
* Roll a dice
The imagination is the limit!