Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There's no way to make a hiring process that makes everyone happy.

Though the length here was not specified, it could be e.g. 3 days that you can do while still employed.




> 3 days that you can do while still employed

That could easily put you in violation of your employment contract. And could result in your (ex-) employer coming after you, and/or your new employer.

I don't necessarily agree that it should, but it absolutely could.


You can make work trials that are obviously not competitive if you are really concerned, e.g. contributing a needed feature to an open source project. Realistically, companies are also just not going to sue.

If people are concerned about the risk of being paid, well, either you want to get paid or not, that's up to them, you can't have you cake and eat it too here.


Sure, but do those 3 days tell you so much more than a 30m interview?

You need to work with someone much longer than that to figure out their (non-obvious) flaws.


They do. You get signals on how well people can work independently on a non-trivial task. How well they can understand their is being communicated to them, whether they clarify what is important, etc. How well they can get themselves unstuck vs needing to ask about everything. How motivated they actually are to work, etc.

They're not perfect, and you really do need to make sure the task is targeted at what you actually want to see from the person when they join, but they definitely give more signal than 6 hours of leetcode.


Give me a take home exercise, doable in maximum 2-3 days and pay me the salary rate for that period.

I'd be happy and it would be fair.


Take home exercises seem so pointless in the AI age tbh. Pretty much anybody can write large amounts of code very quickly these days. It kind of feels pointless to even test this skill.

Plus, most people very lazily state the problem when they give the take home exercise to a point large parts of the problem are open to big interpretation. To the effect any deliverable you produce feels either overdoing or not doing anything at all.

Some people take a part of the problem they are trying to solve at work and just put it in a paragraph and ask you to solve it. Most the times the context is missing, they don't give data you need to complete your work and more importantly it feels they just want this requirement off their table and don't wish to be bothered. So when you go back to them for the data or context, they straight up reject you.

When you do get a company/team, that gives you a good problem to solve. They don't bother to read through your solution. When they do, they want you to go through a live code review in front of the whole team, or work through feature requests on the code you just wrote with dozens of people watching as you type. Then followed by that rounds of grilling you on esoteric trivia. Which in case most companies have a policy that if even one person gives a negative feed back they reject you.

In all, you end up doing lots of work for nothing.


Interesting take home assignment with lots of ways to solve it + technical conversation about the code + checking things like README + deployment steps and whether it even runs or not, I believe, would be very sufficient.

The idea anyway is to find someone capable for solving problems with a specific tech stack, be able to discuss ideas with other people amicably and write decent code.

To me removing the tools which can and are actually using during the job is like asking someone to write flawless code on paper: is that what you are trying to filter for?




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: