4 ms·
Vivek (founder/ceo of hackerrank) here. Appreciate your comments. When we started HackerRank, it was oriented towards problem solving / algorithmic challenges w
by rvivek 9y ago
Vivek (founder/ceo of hackerrank) here. Appreciate your comments. When we started HackerRank, it was oriented towards problem solving / algorithmic challenges which assess a certain level of computational thinking skill -- can you break large problems into sub-problems and solve? I still believe this is a good measure but somehow algorithm challenges have been associated with asking complex red-black trees / graph theory questions which has got nothing to do with actual work.
We have been working super hard (and will continue to) to emphasis on 3 aspects -- problem solving to test computational thinking with basic data structures, role-specific knowledge (for e.g. react if you are hiring a front-end developer) & language proficiency (strength in at least one language) as the 3 pillars.
Given the foundation of HackerRank & the overall associated impression of algorithm challenges, we often get bucketed into a "puzzle company". Obviously, this is on us to make the narrative better and we are working towards it.
Ultimately, the goal of us is to ensure developer experience is great -- showcase your skills in the language/framework you are comfortable in with more time (not a 60-min test). It will take sometime but we are heading in that direction.
- zebraflask 9y agoHumble suggestion: add more front end-specific challenges. I do a lot of front end work. I cannot begin to tell you how irritating (infuriating?) it is to have a company express interest, send over a HackerRank test, and then you find out that they picked a bunch of algo questions that have nothing to do with building a UI. This happens more often than you'd think.
- rvivek 9y agoAgree. agree. we really need to work on that.
- im_down_w_otp 9y agoHi Vivek, My previous employer eventually made HackerRank a requirement for hiring. Fortunately, by that time I had already basically figured out how to freeze the size of my team despite having an absurdly large headcount projection attempting to being forced onto it, so I was able to ultimately abstain from using it (after catching some hell for actively opposing it). However, if I had been in a position to have to use such a tool, there was a major failing in the way it worked (at least 2+ years ago) that would have made it impossible to derive useful meaning for me from the results. What was critical to partially assess for me was a person's ability to fully understand the nature of basic assumptions they take for granted. To get a sense of their completeness of thought and appropriate self-doubt in that completeness. I wanted to do this by being able to provide a black-box implementation of two simple functions: add/2 multiply/2 Both of which would be intentionally implemented incorrectly. Then I wanted to be able to have the user write out property-based tests that would help them discover the way in which the opaque underlying implementation was flawed despite the fact that they would have no internal knowledge of the implementation. This would have very roughly allowed me to assess: 1. How they dismantle basic lifelong concepts that have become mental reflexes like addition and multiplication, but in terms of their properties and invariants (associativity, commutativity, identity, etc). 2. Then also whether or not they could infer what was wrong with the simple opaque implementation based on which properties/invariants weren't holding as they should have. So that I could see how they handled their confidence in the completeness of their analysis. No idea if you could do this today, but at the time the HackerRank system couldn't usefully support the above use case. Or at least the person who conducted the training had no idea how one would do such a thing.