Rant HN: I hate hackerrank • Hacker News Board

Re: Rant HN: I hate hackerrank

#141

Post by passiveincomelg » Sat, Oct 08, 2016, 7:42 PM UTC

One company I applied at last year used hackerrank as part of the interview process. There were two tasks, neither was an "algorithm puzzle". The first was a very simple one that can be checked for correctness automatically (e.g. "remove duplicates from this list of email addresses").

The second one was basically a homework assignment, just timeboxed to 45 minutes or so ("refactor this simple frontend app"). In the following call I expected that we talk about my solution to this task, but we mostly talked about previous projects I've worked on (which was a better use of our time, IMHO).

So I guess what I'm saying is that it is possible to make good use of sites like hackerrank.

Re: Rant HN: I hate hackerrank

#142

Post by 0xmohit » Sat, Oct 08, 2016, 7:50 PM UTC

greenyoda wrote: post #136

0xmohit wrote: post #64

Earlier quoted context omitted.

One day I'll have to work with people who learned from this (and others like it), and it will be a long painful road to help them unlearn. Quoting from the link you've mentioned: #define add(a, b) a + b I couldn't agree with you more. -- To elaborate: add(1, 8) * add(5, 1) wouldn't yield 9 * 6 = 54, but 1 + 8 * 5 + 1 which is 42. One might say that it's correct, since it's the Answer to the Ultimate Question of Life,…

Which is why anyone who has experience programming in C would instead write: #define add(a, b) ((a) + (b))

One may also do:

  add(x, foo(x))

Which is why anyone who has experience programming in C would use (an inline) function instead.

Re: Rant HN: I hate hackerrank

#143

Post by jedmeyers » Sat, Oct 08, 2016, 8:13 PM UTC

0xmohit wrote: post #58

hw wrote: post #41

I loathe algorithm questions, and I almost always never ask them when I'm interviewing a candidate. Too often have I seen candidates who ace 6 rounds of algorithm interviews, only to struggle when it comes to building actual products and require a ton of handholding. On the other hand, I've seen candidates who fail interviews that are algorithm heavy, but have done exceptionally well when it comes to the practical wo…

I've also seen a similar tool that claims to do a partial evaluation of candidate's code. Guess what does it do! Assume that the expected answer was 42 and your code emitted 4 it'd give you 50% marks for the test case. -- As an aside, such tools would give you a 0 even if you coded the perfect algorithm but goofed up the final printf . Robotic evaluations might work, but not in the current form.

I've had a similar problem with one of more recent HackerRank challenges. Part of the input were value pairs, the example contained only two pairs and the ordering of the pairs was not clearly specified, ie it could have been:

x1 x2 x3

y1 y2 y3

or:

x1 y1

x2 y2

x3 y3

The worst part way that their example still produced the same result if you read the values in the wrong order! I spent 40 minutes debugging my solution not understanding why my test cases work perfectly but HR does not accept the solution.

Re: Rant HN: I hate hackerrank

#144

Post by oldprogrammer2 » Sat, Oct 08, 2016, 8:14 PM UTC

maxaf wrote: post #22

I hire engineers for a living, and find intellectually dishonest any interview practice I wouldn't enjoy myself. Paper coding, whiteboard coding, brain teasers, and algorithmic beatdowns are out. Representative take-home work samples and conversational problem solving are in. My candidates are told throughout the process that what we're looking for is a demonstration of how technical collaboration might work if we we…

I couldn't agree more, and I've shaped our hiring policy around the same ideas. I try to be very respectful of the time of both the interviewers and the interviewees, while still providing enough data to make a good decision. I'm sad to say that we learned the most from bad hires: people who were terrible communicators, people who became hostile after hired and their work was critiqued, and people who were expert at talking shop but couldn't produce functioning code on their own.

We typically do a short phone interview first to assess if there is enough common ground to work with. We're looking for huge red flags at this point, such as an inability to talk through very fundamental programming concepts, difficult to communicate with, or a generally disagreeable personality.

Next we do a take home project, where we share a functioning, boilerplate web app, and ask the applicant to spend a couple hours addressing some portion of "requested" functionality. The barrier we're looking for here is actually not very high. We want to see that the applicant was able to figure out was going on in an existing code base and that that they were capable of making a new, original addition to it (even if very small).

The next stage of the interview is an in-person interview with 3 or 4 us. We usually start off with a 30 minute paper test, where the applicant can pick 5 out of 10 questions to answer. Pseudocode answers are expected, not syntax perfection. This is really another datapoint where we're trying to make sure the applicant truly is technically competent.

We then sit down and talk for about an hour. We ask questions about their resume, the project, and the paper test. A lot of this is making sure that they can talk about the things they chose to list on their resume. If they indicate expertise in TDD then they can expect questions about frameworks used and software patterns utilized to improve testability. If they indicate expertise in a particular database server, they can expect detailed questions in that area. This is also an opportunity for them to ask us questions about our company, culture, methodologies, etc.

The final part is a collaborative exercise in defining the architecture of a proposed system. I recognize whiteboarding a solution is tough in such a stressful situation as an interview with people you have not yet developed a working relationship. So we try our best to reassure the applicant, and to make it as collaborative as possible. Sometimes we'll debate different options amongst ourselves to see how the applicant participates and which direction they choose.

I usually close with a tour of our dev area, as well as a few areas of the company so they can see if it feels like a place they could call home.

Interviewing is hard on both sides.

Re: Rant HN: I hate hackerrank

#145

Post by nickbauman » Sat, Oct 08, 2016, 8:20 PM UTC

tspike wrote: post #23

nickbauman wrote: post #6

Knowing the implementation of a specific algorithm is much less important than knowing what class of problem you're facing, where and how to look up the details of algorithms that could help you and how to work well with others to get the work done. If your employer uses hackerrank to choose candidates, you really don't want to work there. People who do those things well are often the worst kind of people to hire: th…

You are overstating your case. Hackerrank is useful as a pre-screen. Give a fizz-buzz type problem on Hackerrank, then proceed with the normal interview process. The kinds of people you are describing would be filtered out in the subsequent interviews.

I can only hope you're right. The tone of the OP doesn't directly support either/or however.

Re: Rant HN: I hate hackerrank

#146

Post by BJanecke » Sat, Oct 08, 2016, 9:04 PM UTC

greenyoda wrote: post #89

retreatguru wrote: post #67

Earlier quoted context omitted.

I wanted to use and like hackerrank as a hiring tool but found the questions had nothing to do with what devs do every day - mainly solving business problems in elegant ways. I even contacted them and told them so but did not get much response. I treat interviews more like going out for coffee and often do just that. I like to understand what people are passionate about both in tech and personally.

"I wanted to use and like hackerrank as a hiring tool but found the questions had nothing to do with what devs do every day" But then... "I like to understand what people are passionate about both in tech and personally." OK, so what do people's personal passions have to do with what devs do every day? Are you really going to hire someone based on whether they prefer playing music, or bicycling, or spending time with…

Hiring someone purely on technical skill is myopic, I'm not going to blabber on about "Cultural Fit" but in small to medium teams hiring someone with vastly opposing viewpoints can be detrimental or it could be greatly beneficial.

How could you expect to measure the social impact of a new member on your team when you look at them as a technical robot and not a human being.

Re: Rant HN: I hate hackerrank

#147

Post by dang » Sun, Oct 09, 2016, 3:28 AM UTC

_RPM wrote: post #105

Seriously why was this flagged? Can't there be some level of criticism without it being censored? Jesus christ anything not in the best interest of making YC money will be crushed.

That's a bad falsehood to spread, since it undermines users' faith in this community. The post was flagged because users flagged it. No one at YC censored it or ever would. The only thing moderators did to this post was unkill (i.e. reopen) the thread after the user flags were enough to kill (i.e. close) it.

HN moderators are strictly instructed to moderate the site less, not more, when a post says something critical of YC or a YC-funded startup. With a post like this one, we would normally have edited the baity title and downweighted the post for being a rant. But because the rant was against a YC startup, we did neither.

Such a policy doesn't stop people from accusing us falsely, but it does let us answer the accusations in good conscience. I couldn't imagine moderating HN without that.

Re: Rant HN: I hate hackerrank

#148

Post by tome » Sun, Oct 09, 2016, 8:36 AM UTC

retreatguru wrote: post #67

erichurkman wrote: post #61

Earlier quoted context omitted.

Having a friendly interview process, to us, is a competitive advantage. As is not requiring multiple onsite interviews, too many phone calls, and even making the onsite interview not take all day (we try to wrap up by 1pm unless a candidate is shadowing an engineer for a day, which we typically do for more senior hires). Having a concise interview process often lets us get offers out the door while candidates are sti…

I wanted to use and like hackerrank as a hiring tool but found the questions had nothing to do with what devs do every day - mainly solving business problems in elegant ways. I even contacted them and told them so but did not get much response. I treat interviews more like going out for coffee and often do just that. I like to understand what people are passionate about both in tech and personally.

> I wanted to use and like hackerrank as a hiring tool but found the questions had nothing to do with what devs do every day

Surely you can add your own questions.

Re: Rant HN: I hate hackerrank

#149

Post by sanketsaurav » Sun, Oct 09, 2016, 12:03 PM UTC

If you look at it, the main problem here seems to be that the way evaluation essentially works (even on the first level of the funnel) has not evolved over the years. People ask algorithm-based questions for assessing developers because there's simply no other tool that allows you to evaluate on these actionable skills. For example, how do you evaluate someone on their understanding of JavaScript's prototypical inheritance? Sure, a text I/O based problem (which HackerRank and others) use cannot help you do this. So you resort to MCQs. Asking a JavaScript guy to solve a problem using dynamic programming simply doesn't make sense.

Technical evaluation needs to evolve.

Re: Rant HN: I hate hackerrank

#150

Post by emilburzo » Sun, Oct 09, 2016, 12:47 PM UTC

samstave wrote: post #34

maxaf wrote: post #22

I hire engineers for a living, and find intellectually dishonest any interview practice I wouldn't enjoy myself. Paper coding, whiteboard coding, brain teasers, and algorithmic beatdowns are out. Representative take-home work samples and conversational problem solving are in. My candidates are told throughout the process that what we're looking for is a demonstration of how technical collaboration might work if we we…

> "Representative take-home work samples and conversational problem solving are in." Exactly. How many times have you reached out to your network and said " HEY! I am trying to solve problemX and I am stuck on Y -- anyone done this before? " You cant expect everyone to know everything - ESPECIALLY in an interview, and even more-so in a panel interview. Measure their problem solving skills, not their intimate knowledg…

> I am tired of everyone trying to be the hero - all my contacts try to support one-another, the interview process should be no different.

Amazing, until you put it into writing I never realized that I do this too.

At least once a day I'll get a random question from my peers in areas where I have more experience than them, which also helped me gain real world work experience years before I even had my first job.

And I do the same when I wander in areas where I haven't had so much experience, discussing approaches and common pitfalls, which makes so much sense.

Yet in interviews it's like you're going to be working alone forever and have to be the best in these exact technologies/languages/stack or you'll never be able to do your job.

I guess this is what you end up with after calling everyone a ninja-rockstar-guru.