Hacker News Reader

The alternative is to push companies to pay for long interviews, be realistic with their requirements (stop asking LC for simple CRUD work), have some faith in schooling, start carrying some risks again, and use the probationary period for what it's designed.

What's happening is companies are putting the burden of the risk on candidates more and more. Because they can. If candidates would put their foot down and stop accepting this, most of these shenanigans would stop. The junior market shows what happens when people are desperate for jobs and willing to bend over for any whim corporate has that might help their hiring process (even when most of it is completely unproven).

> use the probationary period for what it's designed

This is probably fine in an environment where the candidate has lots of other options, but think about this scenario: a person applying to multiple companies, possibly rejecting some offers, possibly relocating or otherwise changing their life, accept that one offer, and then be let go in their first weeks. Changing jobs can be emotionally difficult and being let go even more. If you have to restart your job search, because you were let go during the probation period, all the other roles you have applied to might have been filled. On top of this, contrary to when you were looking for a job last time, now you're actually unemployed and potentially under pressure to find something new.

So, in essence I don't think this is good for candidates.

You obviously can't take the above in a vacuum and think it's fine. You could say the same for the advice of "give people work which resembles what the company does" leading to a situation akin to having interns doing minimum wage work for free, putting pressure on others as a result.

But as things stand, nothing is preventing companies from doing the above anyway. If they think you're a bad fit, they will use the probationary period to cut ties with you. This is perfectly viable today. Your example assumes current filtering methods do in fact increase the ratio of true : false positives, and taking some of them out would decrease that ratio. This is not something that has been proven, and I'd even argue it's something that can't be reasonably proven within the next few years. This is even worse when considering a few interview rounds can only filter for the most obvious dummies, but can't decisively tell you the performance of that individual a few weeks down the line.

What your example does show is how much power employers have over employees. It just isn't healthy for individuals to have to carry this amount of risk while corporates continue to reap the benefits.

> I am also not sure of any good alternatives because someone will always object to any alternative which they cannot achieve for some reason.

When I was on the market, a couple of companies actually gave me a variety of options, which I appreciated. I don't want to spend hours on a take-home and I also don't want to do leetcode, but an open question/answer plus some code review and live debugging was an acceptable combination for me.

Providing the options definitely has the potential to take up developer time, but I think the tradeoffs are worthwhile for both the interviewee and the hiring team.

Whenever they ask me to do a take-home I make a mention that I have about 150k lines of code on GitHub; this is usually ignored. Now, I somewhat understand why larger companies just "follow procedure, even if it doesn't strictly makes much sense" for various reasons, but what baffles me is that even a lot of smaller companies do this; which seems odd since a lot of places I interviewed at are kinda desperate for developers, and often can't match the salaries of larger companies either.

The exception is my current position (only started last week): "oh yeah, we looked at your GitHub already and it's actually similar to the take-home anyway, so little point in that". Instead, they prepared an "alternative" interview where they posed some scenarios with "what would you do? How would you handle this?", which was intended to test both some technical skills, but also social/attitude things. I wrote down some answers, which took me about 30 minutes, and then we discussed them, taking a further 30-45 minutes.

The questions were a bit clunky because they were looking for someone ASAP and there was only 2 days between the first and second interview, but I felt that was a much better approach for the company as well, because they got a lot more information this way: they could already verify basic coding skills themselves, and this way they got a new chunk of information they wouldn't have had otherwise.

>but what baffles me is that even a lot of smaller companies do this

You named the exact problem with the industry.

No one is going to complain if FAANG does this with top tier, life changing salaries. No one will object to learning and memorizing DS&A at a job where DS&A is used heavily.

What people are upset about is your average no-name company hiring individuals based on things they won't use during the job, of which the knowledge is still incredibly varied[0], and they still complain about not being able to find anyone and play the "woe is me" card.

[0]: Dare I say it, DS&A is such a big topic not everyone learns the same things. Thinking in terms of a tree is different from thinking in terms of a linked list, graph, tree, heap, stack, queue, you name it. Most LC medium/hard require time you won't get, information you might not have. This knowledge isn't as universal among skilled graduates as people like to believe. And we all know the moment candidates are able to just memorize questions about linked lists, hiring will jump to the next topic.

> what baffles me is that even a lot of smaller companies do this

Thoughtfully creating an interview process and the procedures/questions is a skill that has to be learned... and when people haven't or don't have the opportunity to learn that skill, it makes sense to turn to resources like books or articles, the most popular of which are often based on FAANG practices.

I also know from my own experience structuring and performing interviews that there can also be a lot of pressure from the top to eliminate candidates following the belief that "the last one standing" is the best, rather than actually trying to evaluate the strengths and weaknesses of every candidate.

That way tends to lead toward interviews of 5-7 rounds that act as sieves.

This is all just my limited personal experience though and I'd love to hear from other people who've done interviewing at/for smaller companies!

> When I was on the market, a couple of companies actually gave me a variety of options, which I appreciated. I don't want to spend hours on a take-home and I also don't want to do leetcode, but an open question/answer plus some code review and live debugging was an acceptable combination for me.

That sounds excellent!

This would allow the company to determine what the applicant believes is their strongest suit.

Then, when it comes time to sit down as a team, and review all the "top shelf" applicants, people can decide, based on a number of criteria.

If an applicant avoided technical challenges, but spoke well, then some managers might like that, but others, might not be comfortable. Maybe they might devise a technical challenge, customized to the applicant, and using real-world problems.

The main deal, is that the vetting has been done. The chaff has been filtered out, so more attention can be paid to the wheat.

At my old corporation, headcount was something I had to fight like crazy to get (I was a manager). We seldom hired, so it was well worth it to spend a great deal of time on each candidate, as they would be responsible for important work, and would have a great effect on the corporate bottom line.

That sounds like a lot of small startups, to me. BigCorp (MAANG, et al) hires thousands of engineers per year. They need to have a cookie cutter system. Smaller companies do it, simply because they want to be like the Big Boys.

Also, and this is neither here, nor there, but binary tree tests are a great "young-pass filter."

A realistic problem similar to what they’ll be expected to d in the job followed by a discussion to ensure they actually understand it makes much more sense than leetcode. Ideally with time for them to complete some of it independently with full access to the internet, an editor, etc.