Hacker News new | ask | show | jobs
by cdicelico 3100 days ago
I feel like you took the specifics around how your evaluation was done and your choices regarding how you solved the problem and conflated those with the entire HackerRank platform, which seems at best disingenuous and at worst intellectually irresponsible.

Regarding the idea that "they expect input and output in a necessarily contrived form", they are giving you a problem to solve. You could say any expectation around input and output is contrived. As a professional, you will not always be able to control this, and need to be able to work against the constraints that are imposed on you.

Regarding the idea that "there is no communication or creativity involved", this is just flat out wrong. You might have had a bad experience due to the way the exercises were set up by the interviewers, but that's not because of HackerRank. What I did is limit the allowed languages and progress people from initial code puzzle screenings to pair programming sessions, where the communication and collaboration evaluation comes in. In every case (puzzles included), there is plenty of room for creativity. In fact, in my own hiring, I have seen a very wide range of different solutions—some very interesting and creative!

I found your choice of Bash to be pretty odd. I'm not sure I'd allow people to write their solutions in Bash, because I realize that a lot of it comes down to fiddling with things like the sed expression you described, which I don't care about. If, as an employer, I want to evaluate your problem solving skills, I'd prefer languages that abstract as much as possible away and force you to focus on the problem as a whole. If, as an applicant, I wanted to highlight my ability to solve problems with code, I would never in a million years choose Bash.

It seems like the way the company you applied to set up the HackerRank platform, mismanaged their communication with you, and selected and configured the questions combined with your choice of Bash, as well as your own personality idiosyncrasies (like getting stressed about the countdown instead of focusing on the problem & remaining calm) came together to create a perfect storm for you, but in my own experience, I've really enjoyed doing their puzzles. I've also had great success using their platform for my own hires and have found that the platform does a great job of highlighting exceptionally skillful engineers and reducing bias in the hiring process. Our team avoided several very bad hires who looked great on paper with the help of the HackerRank platform. So, I think that while it's easy to blame HackerRank, that's not where the real problem is IMO.

The thing with HackerRank is that a LOT comes down to the hiring manager. If s/he doesn't do a good job managing the candidate pipeline, communicating, setting up the puzzles, doing the pair programming sessions, running interviews, etc., then people are going to have experiences like yours. There's no magical platform that will solve for a bad hiring process.

1 comments

Thanks for the detailed feedback! Here is what I mean by "necessarily contrived IO": in a more realistic setting, we might have to answer a question like "what host returns the most 500s?" coming in an email or on a support channel. Or one I actually had to answer a couple weeks ago: "what are our most frequently firing alerts?" That is all of the problem statement right there, not a detailed description of the formatting of the input and the output. Just a user with a question, so you have some work to do to understand what is being asked and how you can find the most time-effective way to answer it. I might have follow up questions like "over what time period? For a particular service or all services of team X? Just in prod or in all environments?", etc. The user also didn't ask for a specific format, I just need to get an intelligible answer with reasonable effort. So based on the context, maybe bash makes sense to answer a one-off question rapidly. In the context of a customer facing app, maybe introducing some abstraction makes sense (again, context). This is whst I would consider a more realistic "on the job" setting, you have to understand users and make trade offs and understand constraints and it's all a little bit fuzzy. In contrast, an online judge necessarily imposes more rigid constraints because of the automated verification -- I don't really see a way around it.
(I work at Hackerrank)

> an online judge necessarily imposes more rigid constraints because of the automated verification

The platform is evolving to not be as rigid anymore as well. For example, we have a product (in a closed beta) which assess candidates on complete projects (eg: build a nodejs app that defines this api and behavior), and testing and scoring is based on unit test cases.

This way, you are testing for more real-world usecases, and also allowing the flexibility beyond straight IO.

That's still just as rigid, it's just increasing scope of the deliverable so a smaller portion overall has to be dedicated to complying with your rigidity.
Interesting, thanks for jumping in! I'd be happy to revise my judgment when I see the new product in action