11–20 of 55 posts
ui doesn't make it clear switching tasks will lose your work, and to make it worse they silently break the clipboard so you can't "cheat" thus preventing you from storing your code anywhere. makes experimentation really awful as you have to keep commenting the whole thing every try
In my opinion they test the wrong things for the majority of software developers. Most people who write code don't need the ability to solve especially hard algorithmic problems. Ranking solutions to hard problems is probably useful if you're Google but there aren't many Googles out there. We like to think that we're solving hard problems (and actually, on HN, we're more likely to be), but most companies aren't. A la…
Disclaimer: I have a stake in https://codility.com/
In my opinion they test the wrong things for the majority of software developers. Most people who write code don't need the ability to solve especially hard algorithmic problems. Ranking solutions to hard problems is probably useful if you're Google but there aren't many Googles out there. We like to think that we're solving hard problems (and actually, on HN, we're more likely to be), but most companies aren't. A la…
You are right that the biggest part of the job is easy - but testing the easy parts is useless - all programmers would pass it. A test must be hard in some way if it is to filter people. Disclaimer: I have a stake in https://codility.com/
HackerRank is just a tool. Its effectiveness depends on how well the company interviewing candidates configures it. I think algorithmic questions are the most popular, but it's completely configurable; you can have it ask whatever you want. It's also possible to manually review submissions. When we used it to evaluate candidates, we'd manually review the code for candidates that scored somewhere in the middle of the range. Depending on what their submission looked like, we'd decide whether or not to proceed with them. (HackerRank lets you see each version of the code attempted by the user, in addition to the final solution submitted.) We actually found it particularly efficient at finding good candidates; there was a very high correlation between interview performance and HackerRank score. If properly configured, HackerRank makes it easier to identify good candidates, which is (IMO) a good thing for everyone. For companies, it means that they spend less time interviewing bad candidates, and for candidates themselves, it means that they might be able to get their foot in the door somewhere where they'd usually get blocked by the "resume scanner" filter (since the company isn't risking engineer time/productivity to send out a simple HackerRank evaluation).
That said, HackerRank isn't perfect. My biggest complaint is the lack of feedback for some failure modes, most notably segfaults and failing non-sample testcases. For segfaults, it simply returns "segmentation fault" and you're expected to be able to find the problem (a similar tool I've seen, coderpad.io, dumps a stack trace). In some algorithmic questions, non-sample testcases include data that is vastly more voluminous than the sample data (which is intended to catch non-optimal implementations of the algorithm), but this isn't obvious at all. It would be nice if the non-sample test cases had titles (e.g. "extremely large input" or "edge case") so you could theorize about why yours failed.
People who have experience using HackerRank have a definite edge over candidates who have never used it before. If you are planning on taking a HackerRank test for a position, I would recommend trying some open questions on their site first. I also recommend having a local text editor, compiler, and debugger ready in case you hit a segfault that isn't immediately obvious. If your solution fails with "Terminated due to timeout", or your code works on all the sample cases but fails/crashes on the hidden cases, then your algorithm is likely not efficient enough (in the timeout case, look for ways to speed it up; in the 'mystery crash' case, look for ways to reduce memory usage). Lastly, if you have extra time after completing a HackerRank test, I recommend making sure your code is as clean as possible and is well-documented (but not over-documented), in case they decide to manually review it.
In my opinion they test the wrong things for the majority of software developers. Most people who write code don't need the ability to solve especially hard algorithmic problems. Ranking solutions to hard problems is probably useful if you're Google but there aren't many Googles out there. We like to think that we're solving hard problems (and actually, on HN, we're more likely to be), but most companies aren't. A la…
Earlier quoted context omitted.
You are right that the biggest part of the job is easy - but testing the easy parts is useless - all programmers would pass it. A test must be hard in some way if it is to filter people. Disclaimer: I have a stake in https://codility.com/
I assure you this is not always the case. I have worked directly with multiple people who could contrive the most exquisite solutions to really difficult problems but whose code was gibberish. Flagging such characteristics during recruitment would be valuable.
In my experience people who understand complex concepts can also understand how to write clear code. Maybe those that you are writing about were not motivated to do that - or maybe it never occurred to them that this was needed?
Would you mind also explaining what you mean by this in "this is not always the case"? Because it does not seem to refer to my comment.
My experience:
1. Works great if engineers apply to you, much less if you try to poach a engineer from great company.
2. Great resumes or credentials sometimes don't correlate with great performance. Especially there are hidden self-trained engineers, who can build great products, but never had CS degree or worked in well known company. It can be competitive advantage if you can give standardized test to everyone who apply, when most companies wouldn't bother to invite them for an interview.
3. Still they can save a lot of time for both ends:
a) candidate usually prefer to spend one hour on an online test than to take a day off for full day of interviews
b) company can offer this test to anyone, time of senior developers is usually too costly to offer regular interview to anyone
4. It is not a replacement for regular interview process. You still have to interview candidate. Most of the time, signal from this tests is clear if they are used properly (e.g. give mix of tasks with different difficulties).
In my opinion they test the wrong things for the majority of software developers. Most people who write code don't need the ability to solve especially hard algorithmic problems. Ranking solutions to hard problems is probably useful if you're Google but there aren't many Googles out there. We like to think that we're solving hard problems (and actually, on HN, we're more likely to be), but most companies aren't. A la…
Agreed. I'm generally much more interested in whether a developer can understand a new problem they haven't faced before, can research possible solution, can compare various trade-offs of solving them and can then implement a solution efficiently and effectively on a constrained time schedule.
I have some stake in https://Codility.com - I could perhaps ask them to add a new kind of tests :)