Live data from Hacker News

Rant HN: I hate hackerrank

news.ycombinator.com

81–90 of 155 posts

Re: Rant HN: I hate hackerrank

#81

> Are we now at a point where an engineer should at all times be intimately familiar with competitive programming and codegolf techniques? Yes, we are. Accepting that trend seems to be better than ignoring it. There is one not-so-bad way to look at these programming challenges. In silicon valley, we live in a condition wherein the company could fail at any time. As a developer, most often, we have to learn something…

> The general idea is, if a developer is diligent enough to prepare for these programming contest problems and delivers when required, he is probably going to be helpful as well when the business has a dire need.

How? It's not like the applicant can study for the "dire need" like they can algorithmic interviews. I mean, sure, such an employee can attack the problem with fervor and hours of time, but that doesn't mean that they'll come up with the right solution to the problem.

The ability to choose the "right" algorithm has no correlation the ability to solve problems: The ability to associate pathfinding problems with the proper variant of Dijkstra's algorithm won't help when troubleshooting why customers are getting intermittent 403 errors.

Re: Rant HN: I hate hackerrank

#82

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.

Do you find that you can determine a person's technical skills from such a discussion? I've found that I'm not very good at determining such things from just talking. Often I talk with people who sound like they know what they're doing, only to find out later that they don't.

As for coffee - do you ask your interviewees if they want that? I don't drink coffee and generally hate coffee shops because the only other options are sugar and fat-filled starch bombs like scones and cakes, and other drinks I don't enjoy like tea. I usually eat a decent meal before interviews so I don't end up unable to think due to hunger during the technical part.

That said, I also find puzzles and unrealistic tests to be annoying. One thing I've done for the technical side is to pull questions from codereview.stackexchange.com and ask the candidate to review them. (I generally print it out and ask them to do it on paper in front of me, so they aren't looking at the existing answers.) This gives me a better idea of their technical skills without the "gotcha" feeling of whiteboards. It also normalizes for different background (e.g. I'm used to Xcode, but this interview had me working in Eclipse and I couldn't find anything!).

Re: Rant HN: I hate hackerrank

#83
I think the point of the take home code example is just filtering out candidates who don't really know how to code. So, I personally think it's ok if you don't pass ALL the tests. An experienced candidate when presented with a DP problem should at least be able to code up a recursive solution, maybe with memoization. They may not get the DP solution correct but at least have an idea of how it should work roughly. You SHOULD NOT have to be intimately familiar with competitive programming to be able to do those things.

Re: Rant HN: I hate hackerrank

#84

One of the things that always interests me around our industry is this. I'm wondering how other industries do it, I mean, once Doctors get their medical license, if they want to move to a different clinic or hospital, do they have to attend an interview demonstrating their knowledge, doing a whiteboard session on a "Dr House" style medical problem that they have to diagnose in Or do they present their medical credent…

My sister is a doctor. In Australia at least, they generally don't bother with interviews or resumes. Right out of university they write down preferences for where they would like to work, and based on their grades they are assigned a position. After that, when moving from one stage of training to another (e.g. resident to registrar or registrar to GP/speciality) they take another test and they are given a position based on their grades on the test. It's like university, but extended to the rest of your life.

Also, in Australia there is the option to do medicine as a 6 year undergraduate degree, which ends up being a very relaxed and easy going degree. Residency and registrar is a 9 to 5 job, where as a registrar you have a six figure salary.

Of course we also have the 4 year long post graduate medicine degree, which would be much harder of course.

Re: Rant HN: I hate hackerrank

#85
Hiring manager who recently added HackerRank to our interview process here.

While far from perfect, I think these types of systems do have some advantages. Keep in mind, I think they are best used as a tool for pre-screening candidates for graduate positions (where we have a LOT of applicants), or candidates we may otherwise pass on due to a lack of well known engineering school or well known companies on their resume (and I'm sensitive to this given that I moved to SF with neither of these). Also, my company is in a very technical problem space, so we do actually use algorithms + data structures on a daily basis.

* I don't buy the "I have 5 years of experience, I should be exempt from coding in HackerRank / phone screens / on-site technical questions" argument. I've done interviews with many people with years of experience and Senior Engineer on their resume, who are unable to solve trivial problems like finding simple patterns in an array. This might not be the majority, but it's enough to create a lot of noise in resume screening.

* As a hiring manager, my job is to make sure that engineers on our team are not getting pulled from their day to day work to do phone or on-site interviews with sub-par candidates. While lots of people on HN tend to complain about interview processes, the reality is that once you start at a job, most of the time you want to focus on writing code and solving technical problems, not performing multiple phone screens per day. Designing a good interview process involves BOTH creating a good experience for the candidate, and not overwhelming your existing team.

* Certainly a strictly better alternative is take-home challenges (which we used to use, and still do for some candidates). However, to get any valuable information from these (and give justice to candidates who spent a couple hours building something), an engineer on our team has to spend time unzipping, running and looking through them, and writing up their thoughts. This might take 30 minutes of their time, and probably an hour or more out of their flow. To do this with more than a couple candidates per week is not possible (not to mention the fact that understandably engineers might not get around to reviewing it for a few days, which is not fair to candidates). For this reason, I think simpler HackerRank type challenges are a better way of pre-screening candidates.

* As a candidate, HackerRank is one of the easiest possible steps for you to pass. Almost all of the problems are up on their website! They may not be exactly the same as the ones given to you by specific companies, but there is a lot of overlap in these types of questions. If you spend a few hours practicing you will be able to ace almost any HackerRank challenge given to you.

That said, HackerRank is a tool, and I think there are a few implementation details needed to make it work well:

* Many of the suggested questions for candidates are terrible (e.g. "will this code compile", or really unclear problem descriptions). For our quiz, I chose all the questions and answered them myself before ever giving them to candidates. If a company lets their recruiters set up a default quiz, it will be really bad for candidates.

* As I mentioned, we usually use this for grads, or candidates who we are not sure about based on resume alone. If you come in through a referral, cold outreach, or TripleByte (who only work with really high quality candidates) you usually get to skip this step.

* I don't think these systems can every tell you how good a candidate is. They can and should only be used as a method of filtering out candidates who don't meet a minimum standard. As others have mentioned, writing algorithms is only part of the job of a good engineer, and they do nothing to test your architectural skills, teamwork skills, motivation level etc. For this reason we only use it as part of our hiring process, as a minimum bar for entry into further interviews.

I'm also constantly looking for ways to improve our hiring process, so open to suggestions to any of the above.

Re: Rant HN: I hate hackerrank

#86

I'll post to this thread because this is very relevant for the hiring companies. Hunter and Schmidt did a meta-study of 85 years of research on hiring criteria. [1] There are three attributes you need to select for to identify performing employees in intellectual fields. - General mental ability (Are they generally smart) Use WAIS or if there are artifacts of GMA(Complex work they've done themselves) available use th…

I'm trying to find a source, but I recall reading the legality of IQ testing is debatable. The same law that outlaws IQ testing also outlawed using educational requirements for the same reason (minorities are underrepresented in higher education.) Yet almost every company requires education credentials, so I don't think it has much teeth. And lots of places use tests like what OP is complaining about, that are basically intelligence tests for all intents and purposes.

Re: Rant HN: I hate hackerrank

#87
post #77

Earlier quoted context omitted.

Part of the interview for my last job involved interviewing me about debugging, which I thought was neat. "What's wrong with this code?" All the samples were relatively simple - less than 30 lines each? - Double delete, caused by not following the rule of 3 in C++, which would likely crash - Multithreading code missing volatile or memory barriers (which segued into a discussion of it's disassembly) - Nonvirtual delet…

Note that unless you are coding in Java, volatile is not a memory barrier, and both the CPU and compiler may reorder things around them.

Yes - perhaps I should have written that as "volatile AND memory barriers". Either way, worth mentioning, as it's a common misunderstanding.

Further complicating matters is the fact that Microsoft's compilers will treat volatile as a memory barrier - for x86 code. But not for ARM! https://msdn.microsoft.com/en-us/library/jj204392.aspx

Re: Rant HN: I hate hackerrank

#89

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"

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 their kids?

Also, since we have a limited amount of time for the interview, I'd much prefer that you didn't waste time asking me personal questions that are irrelevant to the job requirements (or telling me personal things about yourself). I'd rather have time to ask you questions about the job and the company.

Re: Rant HN: I hate hackerrank

#90
I think the problem is people generally look to the big tech companies like Google for guidance on designing their interview process and for those companies it may actually matter that your approach is o(n) vs o(logn).

Big fan of 'homework' to walk through/extend in the onsite interview. The homework should avoid any UI elements and ideally just talk to a database or another API. Another thing to do is try problems that require the candidate to learn something new like a new language, database design, cryptography, distributed consensus, machine learning, geo-fencing, telephony, etc. Strong candidates learn very quickly and enjoy learning new things which usually becomes pretty quickly evident.

Post reply on HN