Hacker News new | ask | show | jobs
by nine_k 3539 days ago
Went through this a couple times lately. No pain.

And the battery of automated tests helpfully written for you saves a lot of time.

If the companies you interview with choose problems you don't find relevant, it may be their fault, not HackerRank's.

Or even not a fault: they have to screen out a number of applicants who are good at boasting but can't actually code. You obviously can. It can be a bit boring, bit it gets you to the next stage with significantly fewer contenders.

4 comments

Yes, the test itself is fine, however the issues I've seen:

- Hidden tests/metrics that also get evaluated

- Companies with an exaggerated sense of self-importance and unrealistic expectation of results

This is a test, you don't have the feedback that you have on a company (code reviews/talking to a colleague/better understanding of the conditions/real data tests/etc). Don't expect me to guess your conditions.

Also, I can't cover all points in the time you give me, I'm focusing on making the thing work, other stuff is secondary.

I feel the time limit is usually the most ridiculous part.

I enjoy solving hard problems as much as any other engineer, or I wouldn't be in this field. But if you want to judge me on code quality, expressiveness, architecture, and test coverage, in addition to performance and correctness, you should really give me enough time to review, refactor and test my code to cover all of those criteria. You know, time that any responsible engineer would spend on any piece of code they write before sending it off to production.

If the position does actually involve writing production-ready solutions to hard algorithms problems within ridiculous time limits like 1 hour, let me know beforehand so I have the chance disqualify myself from it, and we can both avoid wasting any more time with each other.

Exactly. State the conditions and evaluate conformance to the stated conditions, not something else.

It may be a good idea to ask for clarifications before or even when you've started the assignment. (Applies to real work as much or even more.)

This. A thousand times this. I've been stuck with team members that were consummate BS artists. By the time it is apparent, sunk cost fallacy and a desire to save face sets in and the org has to live with them for a long time.
Then you managers are poor I have only ever worked with one person who was totally unsuited for working in IT.
The thing I dislike about the automated tests (and this might have been an option specified by the employer maybe?) is the nature of the test isn't revealed to you.

I remember doing one problem for one company, and the automated test suite just gave you "5 out of 6 tests were passed", without revealing what the 6th one was testing for.

I kept on having to think "maybe it's a null safety check here?", "or here?", what if the user passes -1 etc, but to no avail - the test just wouldn't pass.

The worst part was I gave up in the end because I had to move onto the next question, and they don't reveal at the end your performance and where you went wrong.

Using something like HackerRank as a screen to check that candidates can actually code seems like a good idea to me. But that means setting problems which depend on that, and not specialist knowledge.

For example, an old employer of mine used something like "write a function which, given two strings representing durations down to a hundredth of a second in the format HH:MM:SS.SS, prints the difference between them, in the same format". To do that, you need to do some basic parsing, some simple maths, and some formatting. You don't need clever algorithms.

On the other hand, a problem which requires a "trickily smart O(N) DP solution" requires specialist knowledge, and is not simply a test of whether someone can code. If a company actually needs people who are good at particular algorithms, then this may still be a useful test. But barely any do.

A more ambiguous case is a test i did recently which asked for a function which printed all primes smaller than N. As it happens, i know a couple of (simple!) algorithms for finding primes, so i just coded one. But i know people - including some brilliant colleagues - who haven't studied maths beyond secondary school, and so won't know those algorithms. They might work one out, given time, but that's time they don't have to spend coding.

Frankly, coming up with an inefficient but simple algorithm for finding primes from first principles should work. That is, accumulate primes found so far, check if the next number is divisible by any of them, or even by any number lower than the latest scanned, if you're really bad at number theory, but fine with logic.

Many Project Euler problems are about such special things that you likely didn't know before encountering the problem, but the definition suffices.

"Hackerank" is just the "chitty" culture taking over unfortunately its designed for those who only went into the biz for primarily financial and /or family/cultural pressure