Hacker News Reader

The main problem with some of these things is that:

1) you're expected to spend 3 or 4 hours on some HackerRank test before you've even spoken to anyone. Some of these tests (outside HackerRank) can actually be projects that take a day or more to get right. The issue is that at this point I don't know if the attitude is "hey, this seems like it might be a good hire, let's check if he can actually code" or if it's "let's send anyone this test and discard anyone who doesn't pass". I suspect that in a lot of cases it's the latter. I'm not opposed to investing time, but it quickly becomes unmanageable if everyone just asks you to pass their several-hour tests just to be considered for application. There is very little time investment from the company, and it feels almost like a dDoS attack on my time.

and 2), that a lot of these tests are asking you to solve some hard problem that you will rarely face in real life and where people have quite literally won Turing awards for finding solutions to them. Many previous discussions about this on HN in the past.

I don't think it's even all that much more effective at actually weeding out bad programmers than a simple test. We used to ask people to write a CSV address book importer with some very basic requirements; nothing fancy, you could do it in 30 minutes. It worked well enough, and a lot of the results we got back were horrible.

HackerRank isn't inherently bad. It's actually pretty good. It's that receiving a 1-2 hour automated algo contest to every job application is bad.

If I applied to 10 companies, and every single one of them asked me to come onsite for whiteboarding as the first step, that would also suck tremendously, but at least it would be limited in scope by the employer's time as well. As it stands, arbitrary companies can expect a large time investment without any of their staff ever having to speak to anyone.

I'll take a calculated stab at Amazon's once every 6 months I guess, because if I pass (which I haven't) I can potentially earn a hell of a lot more than any other place. I get it, whatever. If every company is doing it (they are)? I might just leave the industry if I can't find a way to be specifically good at remembering the implementation details of every data structure and algorithm. Sucks to be someone with pointless skills I guess.

A lot of the issue with HackerRank is just how early it is in the process. I don't object to it. But there companies out there that just have every applicant do it indiscriminately.

I agree it's subjective. Some people may prefer HackerRanks because it lets them do the work on their own time without someone watching them. For me, HackerRank problems almost always have nothing to do with my work, require passing an arbitrary test suite, and provide the interviewer with no insight into my problem solving ability. Who would you rather hire, someone who reasoned through the solution on their own, then dropped a hidden test case, or someone who saw this question before and just rote wrote it from memory? Perhaps both, but HackerRank won't give the former a chance.

Besides, if someone is duplicitous enough to have a good looking CV and no coding ability, what's stopping them from just cheating on the HackerRank?

> almost always have nothing to do with my work

TBH that's another argument I don't really get. Almost everyone agrees that basic CS knowledge trumps specific technology knowledge (I'd rather hire someone with strong CS fundamentals that didn't use Java before than someone who is a "Spring Boot expert" but lacks basic CS knowledge, even if I actually use Spring Boot right now).

But then, why complain that you don't do that in your work? Surely you need to traverse data structures from time to time, yeah it won't be the exotic tree traversal that I'd ask you to write but that's exactly the point - to test that you can be put in a novel situation that can't be directly-pasted from StackOverflow and you're able to write a recursive function that takes _a little bit_ of skill).

The hidden test case is opportunity for discussion during actual interview. And this answers your "what's stopping them" question, too - regardless of problem, I can tweak the input slightly so that your solution doesn't work - and more often than not, I don't even tweak the input, I just provide an additional testcase where your solution doesn't work. If you can quickly fix it ("oh, yeah, I forgot that URLs may have a fragment appended to it, let me quickly adjust my log-parsing condition") then it's awesome, it's exactly the signal I'm looking for, and we can go on to discuss system design and your relevant experience (but honestly, at that point my mind is likely ~80% made up, from CV + how you explain/modify your hackerrank solution).

HaackerRank is now 3 hard problems in 1.5 hours. That's not testing anything other than a thousand hours memorizing leetcode.

If there are teams interviewing candidates that are surprised to find that some applicants can't write basic code, then there must also be candidates that are surprised by that as well.

The longer a candidate has worked on very capable teams the more surprised they will be to have those problems presented in a job interview.

There is so much more information gained about a candidate by an engineer interviewing another engineer than by a "pass" or "fail" score from a robot.

You assume the interviewer is ideal: infinitely competent, infinitely great at judging other engineers' skills etc. This is practically never the case.

I am not one for LC type of problems, but at the least I have to admit they have the potential of being more objective than everything else during the interview process. You get the specs, you write the code and it gets tested via multiple test cases. It does not matter if the interviewer agrees your solution will work or not, and the interviewer won't have to copy&paste your code, compile and run it (like someone else mentioned in this thread).

On the other hand, what I particularly dislike about the LC problems is that many of them are essentially trick questions and brain teasers. Can't we just stick to problems that are relevant to an SWE?