Hacker News Reader

Comment by sdrothrock | Hacker News Reader

> 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.

View on HN

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."

Reply on news.ycombinator.com