8 ms·

Rant HN: I hate hackerrank

239 points by throwaway_415 10y ago

I'm currently going through interview stages for several companies for the first time in years and the en vogue trend seems to be a timed hackerrank test. Without fail this involves an algorithms-heavy rip off from leetcode/projecteurler/googlefoobar/topcoder culminating in some trickily smart O(N) DP solution. I'm an experienced developer with 5 years of thorough product experience in the domain. I'd completely appreciate the importance if the role actually did involve trying to eek out efficiency in a distributed system with high throughput... but 9 times out of 10 it's boilerplate business logic. On the one hand I like that it normalises the application process against prejudice (I was lucky enough to go to a top engineering school) so it allows a fair entry level to all, however, it appears to be just an utterly irrelevant IQ hazing. Anyone else going through this pain? What are we to make of the recruiting scene going forward? Are we now at a point where an engineer should at all times be intimately familiar with competitive programming and codegolf techniques?

sotojuan 10y ago
The worst part of Hacker Rank is that it takes arguments as STDIN, forcing you to to a "read from STDIN" ceremony before actually getting to the problem.
- natdempk 10y ago
  I could see why that might be annoying, but it forces the coder to make choices about their data structure and makes it easier for hacker rank to support many languages.
- akerl_ 10y ago
  If reading from STDIN is something that's considered a "ceremony", I'm already concerned about the rest of the code. STDIN is one of the most common input methods I use for most of the commands I interact with on a daily basis. It would be like discovering that somebody found "logging errors to STDERR" to be a "ceremony"
  - deleted 10y ago
    [deleted]
  - coredog64 10y ago
    The days of Perl CGI are a distant memory. More than that, it is a distraction. I'd be happier with the use of a parameterized test framework that lets you get to the point much more quickly.
  - peruvian 10y ago
    In real life, I agree. But if I'm trying to solve an array sorting problem, why can't they just give me an array? LeetCode does it and it works fine. I get to focus on how to sort the array. The other commenter (natdempk) makes some good points though.
  - jakobegger 10y ago
    If you work with a modern framework, chances are high you'll never actually read from STDIN. For example, I have no idea how I'd read from standard input in ObjC or Swift.
- twic 10y ago
  In most of the problems i've done, there's boilerplate code to read from standard input supplied as part of the problem. You just have to implement the algorithm. In the problems where it's not, yeah, it's annoying. But it's also the same one or two lines every time, so it's not a big deal.
go_go_ 10y ago
This is one of the reasons I'm eyeing management for long term career growth. I've learned that the problems given to sr. and jr. engineers are roughly the same, and that the interview process is biased towards jr.
- rajeshmr 10y ago
  I think the same way. Mostly biased towards jr. And management seems like a good option for long term career growth.
  - imjustsaying 10y ago
    Isn't it a bad omen for any industry when the most realistic career advancement path is management?
    - bshimmin 10y ago
      Isn't that how most industries work, from flipping burgers to the legal profession? Why should tech be any different?
      - rajeshmr 10y ago
        True, also the industry prefers younger population coz they can burn more hours and are available for a cheaper than the experienced folks. Also, the industry somehow seems to stereotype a developer as some younger geeks. The stereotype works against experienced folks sometimes (not always).
    - rajeshmr 10y ago
      If we had a sane choice we would still stick to tech - tech is like the first love that is going through a rocky phase! I believe there is the "collective stupidity" problem in the tech industry where a new framework pops up almost everyday, a new language every now and then and the sheer volume of knowledge to accumulate to stay relevant is abysmally high! With the realities of life taking over, the path is inevitable to most senior people.
orsenthil 10y ago
> 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 entirely new and ship the code for the business. Those challenges are quite enormous with lots of unknowns compared to these programming contest problems where it is just preparation. 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.
- nicksergeant 10y ago
  On the flip side, now you have no idea if a developer is any good, because all they have to do is memorize a bunch of garbage interview algo techniques / questions.
  - tspike 10y ago
    What is your preferred interviewing method?
    - tluyben2 10y ago
      For people with 5+ years of experience (like OP), I look at and talk about their portfolio; he did actually built stuff that runs in production, so let's see how that came to be. And show parts you have written and are proud of. We are probably in that interview because your skill set matches (somewhat) the problems we are trying to solve, hence your past projects will have similarities with our projects. That interests me. I can find out if you are a self starter, if you have any business sense by chance, management/tutor potential etc. That you can solve some complex thing in 5 minutes is of no interest to me at all, ever.
    - MaulingMonkey 10y ago
      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 delete through base pointer Extremely realistic - it's all stuff I've seen and fixed in the wild (this was for a non-entry gamedev job involving plenty of C++)
nickbauman 10y ago
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: they're really good at certain types of problems but suck at almost everything else. I end up cleaning up systems after these people all the time everywhere I encounter them in the workplace.
- lprubin 10y ago
  Exactly this. The hiring process cuts both ways. Unless you're desperate, you should also be evaluating your employer and the quickest way for me to walk away is to filter candidates through something like hackerrank rather then something much more applicable to what I'd actually be doing as a programmer at the company. It shows me a big disconnect between hiring and the day to day and gives me no indication on the skill level of the team I'll be working with.
- tspike 10y ago
  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.
  - nickbauman 10y ago
    I can only hope you're right. The tone of the OP doesn't directly support either/or however.
ktRolster 10y ago
It's annoying, I agree, and sometimes on hackerrank the problems are miscalibrated, but the best way to handle it is to just do it. They aren't that hard, so spend a week or so getting your skill level up.
pweissbrod 10y ago
maybe what you should really hate is a company that adopts the en-vogue trend as the standards for recruitment. think about what that says about the team that passed their interview
- rajeshmr 10y ago
  Well said!
evilc0 10y ago
I completely agree with you. Measuring our skill based on HackerRank is completely bullshit. I'm 100% sure, every programmer-beginner (even every math student) can solve the problems on HackerRank but can't even deploy a application on server nor know how to deal with real customers nor read a build-script nor... (image a lot more things here)
EliRivers 10y ago
As an aside, I also dislike hackerrank; for me, it's the sheer ham-fisted ineptitude of some of the alleged learning exercises. Look at this mess: https://www.hackerrank.com/challenges/preprocessor-solution https://www.hackerrank.com/challenges/preprocessor-solution This purports to be teaching use of the preprocessor. It's horrific. It's someone's amusing "look at how you can create your own programming language by abusing the preprocessor" mess; fair enough, it's always fun to see someone do something this painful, but this is being genuinely presented as a preprocessor learning exercise. 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.
- 0xmohit 10y ago
  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, the Universe and Everything.
  - greenyoda 10y ago
    Which is why anyone who has experience programming in C would instead write: #define add(a, b) ((a) + (b))
    - 0xmohit 10y ago
      One may also do: add(x, foo(x)) Which is why anyone who has experience programming in C would use (an inline) function instead.
daveguy 10y ago
The important thing is not to ace the final result. The important thing is to communicate your thought process, identify bugs, talk about options in architecture and design, stay calm under pressure and keep a positive attitude even when asked to do something you think is silly. The interviewers know "this exact problem" is not generally applicable to their work. They are looking at how you interact with the problem. Projecting a bad attitude toward being asked to code on a whiteboard is the opposite of what you should do and misses the point entirely. Code golf and competition (right answer in min time) is not the point.
- ojr 10y ago
  you can't communicate your thought process on hackerrank or triplebyte it is a timed online test
nine_k 10y 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.
- coredog64 10y ago
  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.
  - walshemj 10y ago
    Then you managers are poor I have only ever worked with one person who was totally unsuited for working in IT.
- djhworld 10y ago
  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.
- raverbashing 10y ago
  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.
rajeshmr 10y ago
I face this problem. I am into server side scripting and automation and this hardly involves algos and stuff. The problem doesn't seem to lie with hackerrank but with one-size-fits-all HR approach. I would also pin the blame on lack of understanding on the part of HR personnel (they seem to be the drivers behind recruitment drives) of how the tech landscape is.They need to educate themselves on what sorta interview process to be conducted for different profiles.
- skybrian 10y ago
  That seems... limiting. Are you sure you want to specialize that much, and rule out doing any programming that does require understanding something about algorithms?
  - rajeshmr 10y ago
    I do know algorithms, it's just that I don't use it in my day to day activities. When confronted with an online challenge with time constraints I seem not to cope since I hardly use algos in my day to day automation it isn't right on top of my fingertips! Without time constraints I am able to solve the problems. Timed Algo assessments are very similar to exams u write in universities.. u need to keep practicing to complete those assessments in time and get a "pass mark".
maxaf 10y ago
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 were employed by the same company. This takes away most of the stress of interviewing, which I know via candidate surveys. My advice would be to steer clear from employers who use a soulless cookie cutter process that makes people feel like a commodity. This is how you'll also be treated during daily interactions and in conversations about your career development. Don't be under any illusion that you'll be able to find yourself on the right side of such a situation.
- samstave 10y ago
  >"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 knowledge of tech/lang X.... and then on-top of that, judge their fit for working well in the team! only ask that when they come back from a takehome issue, that they say exactly how they solved it: "I had to call my buddy over at BigCorp and say, hey dont tell me the answer - but lead me to where I might figure out how to solve this problem" OR "Hey joe, I did this - but i am not sure how efficient it is - did you do something similar?" Tell them to get a slack channel of their peers to help them succeed. 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.
  - emilburzo 10y ago
    > 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.
d23 10y ago
Recruiting and hiring are garbage right now in the industry. Part of the problem is easy to recognize -- idiots designing interviews. This is where the puzzle crap comes from, as well as theoretical stuff that's far removed from the day to day of what a person will be doing. The other problem is that the people who could be designing better interviews aren't stepping up. There are plenty of intelligent people who aren't 1) taking the time and effort to introspect and think about why they are effective as people and 2) taking those insights and translating them into an interview process that selects for important traits in simple, reproducible ways. It's bizarre. A job could require years of experience with linux, programming, and networking, all of which could be tested with a multiple-choice style test to get a sense of where a candidate stands. Instead, we look at their resume, check off that they have our requirements buried somewhere in the forest of buzzwords, and then move onto whether someone can finger-paint their freshman year CS lectures onto a whiteboard. Then when we end up hiring a completely ineffective person who spent their entire time trying to game the interview system, we are surprised, even though we've been selecting for that kind of person all along.
- IndianAstronaut 10y ago
  Another thing missing from interviews is being able to find various talents in engineers for the diversity of the engineers out there. Are they good at finding corner cases, are they creative with product design, are they good communicators with a non technical audience.
- yitchelle 10y ago
  > This is where the puzzle crap comes from, as well as theoretical stuff that's far removed from the day to day of what a person will be doing. I find looking through past project work is one of the best indicators of their ability. However I have found this to be extremely difficult to get. NDA restrictions of their previous employers is one major restrictions, or he is transitioning from a different domain or career path.
samstave 10y ago
As an aside.... I find it ironic that almost all companies talk about "culture, family, work-life-balance" yet they treat recruiting as robot selection.... IQ Hazing is a good way to put it... but how do you measure, "Do I even want to fucking work with these people/this company???"
eyelidlessness 10y ago
> I'm an experienced developer with 5 years of thorough product experience in the domain. I'd completely appreciate the importance if the role actually did involve trying to eek out efficiency in a distributed system with high throughput... but 9 times out of 10 it's boilerplate business logic. This is what I don't understand about software engineer hiring. They are ignoring important criteria about fit for the actual job, and focusing on criteria that is either orthogonal or completely irrelevant. It's worthwhile to ask in these situations if the exercise is representative of work you'd be doing. It almost never is, but they tend to excuse it as... > it normalises the application process against prejudice But does it? By ignoring the actual criteria relevant to the job, they're dumping qualified people who don't do well with the hazing, and delaying evaluation of everyone else until after they're hired. That evaluation tends to be a lot less objective, because "hiring is expensive"; it selects for people who do well with the hazing, and reproduces the problem for the next round.
- bunderbunder 10y ago
  > This is what I don't understand about software engineer hiring. They are ignoring important criteria about fit for the actual job, and focusing on criteria that is either orthogonal or completely irrelevant. Oftentimes, the people actually designing the hiring process have an imperfect understanding of what work software engineers actually do. They ask the software engineers for input, but optimizing the hiring process to be orthogonal a software engineer's core work responsibilities, so they aren't necessarily going to give ideal advice.
git-pull 10y ago
For their own expedience. It's an employer's market. It costs 2.5k/yr to keep an SO posting up and get thousands of resumes in your inbox. I'd also say a fair share of those in Who's Hiring on HN aren't in dire need of filling seats, but just trying to see how far people with fling themselves through the mazes. Blissfully unaware they're not the only startup and have no way of offering the stability of a large company. At one of the places I've seen, we didn't read every resume. We overlooked mountains of talent and shot ourselves in the foot. Instead of hiring coders that had their heart in the right place, we hired streetwise careerists that put their own interests before the team. But they could do palindromes, fizzbuzz, and whiteboard data structures and algorithms. But when we wanted them to do something generalist or in another language, they'd refuse. One even went so far as saying if they could program X in Y editor, they'd just leave the job. What use is passing all these tests if you're totally inflexible? We also snubbed people enthusiastically espoused the startup gumption and idea of building, but didn't cope well with the white boarding we thrown at them. Those whose heart was in teamwork and open source, we overlooked ignorantly, while continually putting up walls to see who finally gets past all of them. There is some toxic cultural thing amidst in startups of insularity and smugness. If I could go back, I'd say screw it with the whiteboard games, come freelance with us for a week. That way I can gauge your temperament, how you work with teammates, your technical skills, etc. in a realistic setting. And if someone asks for a code sample, and you already have projects on GitHub or your portfolio, don't be afraid to redirect them to that instead. If they don't look, assume the employer is not serious about filling the spot, but just putting in the least effort themselves to see how many hoops people jump. It's not you OP / other programmers. If an employer doesn't bother to give you a phone call to talk to you as a human being, maybe they're not so eager to have a position filled. Don't let it effect your self-worth. Always be coding. Don't be afraid to stick your head out there at a meetup and shake some hands, you'll be surprised how much more decency you court when you represent you're a human being, not another resume in a stack of thousands.
- bunderbunder 10y ago
  "Come freelance with us for a week" seems even worse to me. For starters, there is a very small and fairly specific subset of the population that can afford to carve out a whole week for an extended interview, even if you do pay them for their time.
k2xl 10y ago
Sort of surprised to see most of the comments on here actually defending the companies that put so much weight on these types of tests. I think many people assume that interviewers are looking for "thought process" but from my experience as a hiring manager for 6 years, in reality you'll find that most are just looking to "gotch-ya" the candidate. Many interviewers seem to enjoy making a candidate "sweat" as some source of pride. Again, not saying everyone does this, but often times programmer interviewers believe that the harder and more obscure a programming question is the better. We should all agree that coding tests are helpful in assessing a candidate's programming capabilities, but not all coding tests are equal. From my experience, bad coding tests that have little relation to whether a candidate will do a good job are these arbitrary ones. For example: * Implement a merge/quick/radixx sort algorithm that you maybe did 10 years ago in college and have never had to do since. * Implement a linked list/hashmap/some other random data structure in Java even though you would never write on yourself. * Write a program to determine whether a string is a palindrome. * Implement an algorithm to solve this random problem from Project Euler Ones that have been worked better attempt to be comparable to what they actually might do in the company: * FizzBuzz - (While controversial, this helps weed out people who just don't know how to code) * Build a JSON REST API in whatever language you want to manage groceries in a shopping cart. * Write a web scraper in whatever language you want to count the most popular words on a website * Here is a random UI framework that you have never used, use whatever documentation you can find on the web and write a To Do list application with it. Again, YMMV, and depending on your domain certain questions make more sense to ask than others. If you're interviewing as a researcher for Google/Amazon/IBM/Microsoft, then you actually might need to know how to implement some random sorting algorithm because it may be what you will need to implement it in some new SDK/library. But I don't believe that for most companies this makes sense. If you are a hiring manager, ask yourself this: If you had to run one of your current (positive) team members through your current interview process, would they make it through? Would they say they had a positive interview experience?
- bostik 10y ago
  > I think many people assume that interviewers are looking for "thought process" but from my experience as a hiring manager for 6 years, in reality you'll find that most are just looking to "gotch-ya" the candidate. Many interviewers seem to enjoy making a candidate "sweat" as some source of pride. What you describe is a horrible approach to interviewing, and points towards dysfunction more than anything else. In my opinion, the second most appealing non-technical character trait for an engineer is empathy. (Curiosity being #1.) If you have an interviewer who goes on a power trip and actively tries to abuse a candidate, what does that tell you about their company? Everything is PR, and how we interview engineers tells a lot about how we deal with each other. Would you like to work in a place where being nasty is considered normal - or even desirable?
hw 10y ago
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 world - doing actual work and building apps and contributing to the team instead of writing the next (insert your fav tricky algorithm question here) solver. It's unfortunate that while many companies that are hiring are just run-of-the-mill SaaS and apps companies that don't require you as an engineer to use algorithms or DP on a daily basis (or even ever), you still see algorithm heavy interviews at these companies. On Hackerrank, I don't necessarily hate it as a tool, but just the questions that get asked through it. I don't like that it automates an interview process to a certain extent, as a candidate's potential and skills and experience and fit in the team can't exactly be measured via an automated process but requires actual human to human interaction. If a company rejects you on the basis of failing a Hackerrank question and hasn't even talked to you, you're better off working for a different company.
- 0xmohit 10y ago
  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.
  - jedmeyers 10y ago
    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.
djhworld 10y ago
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 < 10 minutes? Or do they present their medical credentials, and get interviewed on their bedside manner, their ability to work in a team (if applicable), anecdotes about their past experiences etc?
- llamaz 10y ago
  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.
- lloyd-christmas 10y ago
  Med school is difficult. An internship is difficult. A fellowship program is difficult. Undergraduate degrees are a rubber stamp, CS included. There are 20k oncologists across all fields of oncology within the US. That's also about the number of engineers Google employs. Most other industries we like to compare ourselves to are leagues above ours in individual merit. My father is an oncologist, and I'm reasonably confident he has some familiarity with every genitourinary oncologist in North America, Australia, and Europe. More importantly, he's on a first name basis with all of their educators. When he needs to hire a new doctor, he doesn't post an ad on health stack exchange. He makes an offer to a specific individual who he already knows. One thing that we as an industry fail to understand is that we're not special. We desperately claw to it in these conversations. I'm willing to admit it: I'm easily replaceable. Very few of us have any name recognition that exists in other fields. I worked in finance for half a decade before moving to software. When I'd go to interview, people already knew who I was because of the basic human interaction I had as part of my job. When I walk into the door of my next interview, the only thing people know about me is what's on my resume/blog/stack overflow answers. Personally, I find technical interviews to be a cheap and easy filter. You may not always get the best person from your pool of applicants, but you get someone that's better than most of them. The marginal benefit of one vs. the other is rarely meaningful. OP complained about having to do this, but some of the other applicants might have found it difficult. Sounds like it was successful.
jacques_chester 10y ago
Here's how I was assessed for my job at Pivotal: 1. I did a simple tech screen (the RPI). 1 hour. My interviewer had a laptop and asked me questions about what to do next in the scenario. 2. Hey, come pair with this engineer on this real code on a real project on a real task. 3. How about lunch? 4. Hey, let's have you pair with this other engineer on real code on a real project on a real task. 5. Get offered a job on my way out the door. I know from feedback that we don't always do this right, that we sometimes drop the ball, that many people find the RPI or the pairing to be frustrating, intimidating, or uncomfortable. Most importantly, many people find that they just don't want to work the way we prefer. Which is good! It saves them the unhappiness of committing to a situation that won't enjoy. But the core insight is: the best way to see if someone can work alongside us on a real problem is to ask them to come in to work alongside us on a real problem. It's the best proxy we have short of hiring you. When it's available as an option to do this, I don't understand why anyone would choose a less accurate proxy.
- 0xmohit 10y ago
  It's also a fantastic way to see how one thinks, one's problem solving approach, debugging skills and the like.
  - jacques_chester 10y ago
    It is! I hasten to add that it isn't perfect. We hire across the intro-extraversion spectrum, but there's an ongoing concern that we're biased towards extraverts. Especially in Labs, which is the consulting wing. Another problem is that many candidates are just plain nervous. We do our best to set people at ease and to be upfront that there's no right or wrong or trick answers. But interviewing is just scary. I expected to fail and so felt no pressure -- had I felt that more was on the line, maybe I'd have done worse. The third -- this is a very common negative opinion -- is the argument that we don't give candidates a fair opportunity to show their expertise. We will usually try to assign one project where their résumé claims expertise and another one that they're unfamiliar with. The former to take a sounding of their expertise, the second to get a feeling for their approach to the unknown. It's not always possible to do this, simply because it's a vast field and candidates come with very varied backgrounds. And those candidates who are declined often feel that we've denied them a fair chance by throwing them into an unfamiliar technology. These are all fair criticisms. My best answer is: we are not trying to trick or exclude anyone upfront. Ultimately the hiring decision is made by future peers, so we want to be fair but firm. Hiring is just hard.
quantumhobbit 10y ago
I don't mind algorithms and brain teasers if they are presented well. As in the interviewer makes it clear they aren't looking for a single right answer but want observe how you solve a problem. Plus I enjoy a good puzzle. My problem with hackerrank is that the problem statements are often unclear and have artificially short deadlines. I feel like it forces my to use unreadable and sloppy coding to just get any solution out the door before the timer runs out.
throwaway_415 10y ago
Just to add two points that bother me the most: 1. It doesn't actually test my ability. Most of the time there is a stackoverflow solution and I'm going to just look it up and regurgitate it. I can't remember where I read this but allegedly it took Knuth a day of thinking to come up with the most optimal solution for one of the presented challenges (it was either the maximum subarray sum or stock sell problem). 2. It's all very well preparing for these interviews at my age (under 30, no responsibilities or family, generous severance from my previous employer), however, what happens 10 years down the line with responsibilities and hungry mouths to feed.
0xmohit 10y ago
Not many within a team that is hiring either have the time or skills to assess candidates. Employers are looking for a magic solution to fulfill their staffing needs. Companies such as Hackerrank have thereby managed to convince employers that they have the solution to all the hiring problems. Essentially a magic wand which would enable them to hire Einsteins.
newjobseeker 10y ago
I'm going through this right now. I've taken some time (1+ years) off and do admit to being rusty. However, I've dedicated time to studying and I'm not getting past some technical phone screens because of these algorithms-heavy questions. I do well enough on them yet are passed over. I thought the market was "hot" and this would be relatively straightforward, but it has been anything but easy. I'm also starting to wonder if there are other factors at play (ageism, female).
fixxer 10y ago
These things are really just filters. Due to the legal aspects of hiring/recruiting, especially at large companies, these exercises are par for the course. Once you're in a large company, firing can be very difficult, so I'm all for filters. Personally, after having taken many of these tests myself, if you're having even minor problems, that is a huge red flag for me. They're really just binary filters on basic skill level.
- walshemj 10y ago
  With the USA's at will and limited worker protection you must be kidding about how hard it is to fire people
  - fixxer 10y ago
    In my experience, it is very hard to fire people if they are simply incompetent. You can fire them for mistakes, but just sucking at one's job is this awkward grey area where you wrestle with HR and they usually suggest investing in training, etc. That is fine and good, but when I got a deadline, I'm not going to tow deadwood.
spitfire 10y ago
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 them as proxies. Using IQ is effectively illegal[2] in the US, so you'll have to find a test that acts as a good proxy. - Work sample test. NOT HAZING! As close as possible to the actual work they'd be doing. Try to make it apples-to-apples comparison across candidates. Also, try and make accomidations for candidates not knowing your company shibboleth. - Integrity. The first two won't matter if you hire dishonest people or politicians. There are existing tests available for this, you can purchase for < $50 per use. This alone will get you > 65% hit rate [1], and can be done inside of three hours. There's no need for day long (or multi-day) gladiator style gauntlets. [1] http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%20Validity%20and%20Utility%20Psychological%20Bulletin.pdf http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%... [2] The effective illegality comes from IQ tests disadvantaging certain minority groups.
- Houshalter 10y ago
  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.
- thedufer 10y ago
  > Using IQ is effectively illegal[2] in the US, so you'll have to find a test that acts as a good proxy. You've posted this before and been called out on it. Please stop spreading misinformation. There is nothing special about IQ tests specifically. Any proxy test will have exactly the same legal ramifications. As long as you can show that the results of that test are relevant to job performance, it is fine. Whether it is labeled an "IQ test" is irrelevant.
deleted 10y ago
[deleted]
inverse_pi 10y ago
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.
amacneil 10y ago
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.
Houshalter 10y ago
What about for people with no experience or education? I'd love the opportunity to prove myself through testing rather than relying on credentials I don't have.
siliconc0w 10y ago
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.
jandrewrogers 10y ago
It could be worse. My personal recruiting peeve is what I call the "Dunning-Kruger interview", where they ask algorithm questions they don't understand and don't even realize that fact. It is unfortunately common, and made doubly worse when it is plainly my area of expertise and the reason I was recruited in the first place. More than once, I've been recruited by executives at Famous Tech Company to run major new initiatives involving vast volumes of spatially organized data, since my expertise in that area is well known, but there is a technical diligence step where I am grilled on spatial algorithms by a shockingly ignorant (e.g. doesn't understand R-trees) Principal Engineer or similar who actually believes no one can know more about the space than they do. (If that was the case, they wouldn't be trying to recruit me.) If an interviewer wants to test my expertise, they better be able to have a substantive discussion on the subject matter and understand the limits of their own expertise. I view algorithm gotcha games as disrespectful of an experienced software engineer's expertise generally. I like to turn it into a substantial discussion about the algorithm class generally; if the interviewer is incapable of having a substantial unscripted discussion about said algorithms, it is a red flag and they have no business asking those kinds of questions. These days, I just walk away from an opportunity when this kind of nonsense happens.
- greglindahl 10y ago
  ... maybe the point of putting you in with the shockingly ignorant Principal Engineer was to figure out if you could work with them?
  - jandrewrogers 10y ago
    Heh, possibly, but in practice it usually appears to stem from complete disinterest -- it is an assignment and they do minimal background investigation. I go along with it, but in one extreme case I had a PE-type flatly accuse me of not understanding the theoretical details of a particular algorithm, being unaware that I invented it (and I never mentioned that). When it gets to that point, it is a lost cause. Some computer science domains are worse than others. Spatial is particularly bad because very few computer scientists realize the theoretical foundations of spatial data structures are completely different than the more ordinary ones they are familiar with -- their intuitions don't apply.
guessmyname 10y ago
I have +6 years of work experience as a developer and for the last two months I have had +36 pre-selection interviews via HackerRank with a wide range of small to medium sized companies. I am not ashamed to say that I have failed every single one of them, but I have to recognize that I have learned more things during the last couple of weeks about algorithms, data structures and prioritization than in most of my career. This week I was invited by an in-house recruiter from one of the "Big 4" to resolve two coding problems via HackerRank in 120 minutes, plus a third exercise asking about the time and space complexity of my solution. I am 99% sure that I will fail this pre-selection too, but I really do not care, the more I practice now the more opportunities I will have next time. I have talked with people who were hired by Google, Amazon, Booking.com after 8-12 months being unemployed, so — in my case — two months is certainly nothing, I can use the next six months to train myself and maybe next year one of these companies will extend an offer and then I will forget about all this hiring madness.
markbnj 10y ago
Organizations seek out formulaic ways of qualifying candidates because actually assessing an individual's talent and personality takes time and effort, and is a significant investment. The pressure to streamline the process grows as the company grows and hiring becomes a more frequent thing. It's one of the main reasons I like working for small companies. As a case in point I'll describe the process that led to my current position. After the application and a brief phone call I was given a take-home project with a one week deadline. The project was directly related to what the company does, and was interesting and fun to do. I submitted a pull request in four days. The pr was reviewed by their engineering team and they all voted to move me forward. The next step was a work along day for which I was paid. These are typically done in person but for various reasons on both sides we did it remotely. The entire engineering team participated in a dedicated slack channel as we walked through my homework project, suggested and implemented changes, joked and in general had a good time. At the end of the day I said my goodbyes and an hour later the recruiter called to tell me they were preparing an offer. The advantages of this process should be readily apparent. By the time my first day arrived we already knew we'd get along, approached work in compatible ways, etc. The costs of the process should also be readily apparent, and it would probably be really hard for a larger company to do things this way.
_RPM 10y ago
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.
- retreatguru 10y ago
  I agree, not sure why this was flagged. The title is clickbait, but it seems this guy genuinely does hate hackerrank. fair enough.
  - _RPM 10y ago
    Because its bad PR for hacker rank. That's why it was flagged.
    - retreatguru 10y ago
      Ironically often any PR is good PR. So many people who otherwise would not hear about hackerrank will now hear about it and many will use it regardless.
- throwaway_415 10y ago
  Possibly because I'm brand new (I'm not, I'm a very long time lurker and one time failed YC applicant).
- dang 10y ago
  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.
noir_lord 10y ago
I just wouldn't apply anywhere that does that, it's a ridiculous way of testing a developers fit for the average role and a strong warning indicator that it'd be somewhere not to work.
hvd 10y ago
if you don't like hacker rank. suggest a technical phone screen over a shared notebook or a homework problem as an alternative. See how that works.
StreamBright 10y ago
Our hiring process uses only homework. We give you a problem to solve, a single Java file to do code review on and some database problems that you have to solve with MongoDB. Based on how well you do we go for a phone interview and if it goes well we bring you in for an onsite interview. I tried HackerRank a while back but it does not give us too much value. The competition going on it can be fun for programmers who like challenges like that but it has almost zero indication how well you are going to do in a production environment working on a mission critical system with a team and where your code is running on any infrastructure. Using it as a hiring tool is fundamentally flawed in my opinion.
jsonau 10y ago
@OP: You sound almost exactly like me. I have not done any interviews for a bit more than 5 years. I think the what really can be improved is to test us in a more familiar and friendly environment. I have to spend time on handling time-pressure, and fix/adapt with my thinking habits. ## Coding Problems: I do think coding challenges(algorithmic) has merits, but I think there are two factor that really hinders a interviewee's performances: - time limit - require an unfamiliar algorithm Time limit is obviously needed in a test, but problem solving in real life is never instant unless it's done before. Nevertheless everyone have their own pace. I have to dedicate hours each day to train myself to adjust my brain to act quicker yet calm for these algorithmic questions. Sometimes my initial solution in my mind turns out to be the best, but I discard it. Nevertheless if one is stuck, the time limit just makes it worst. I'm also known to be the slowest in turn-based board game -- I have high win rates though! ## Possible Solution? * Allow interviewee pick from a pool of equally-difficult-challenges to solve (within a minute or two). This can solves the "obscure algorithm" or "trick" question. This also helps the time-limit problem as the interviewee WILL interpret the question twice in two different VIBES (with and without time pressure) Even choosing 1 out of 2 would dramatically reduce nervousness and time pressure.
passiveincomelg 10y ago
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.
sanketsaurav 10y ago
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.
rl1987 10y ago
There is no shortage of reasonably competent software developers in USA and West Europe. The very existence of things like Codility and HackerRank proves that. However, there is significant shortage of sanity and common sense in the culture of developer hiring.

239 points by throwaway_415 10y ago

sotojuan 10y ago

The worst part of Hacker Rank is that it takes arguments as STDIN, forcing you to to a "read from STDIN" ceremony before actually getting to the problem.

natdempk 10y ago
I could see why that might be annoying, but it forces the coder to make choices about their data structure and makes it easier for hacker rank to support many languages.
akerl_ 10y ago
If reading from STDIN is something that's considered a "ceremony", I'm already concerned about the rest of the code. STDIN is one of the most common input methods I use for most of the commands I interact with on a daily basis. It would be like discovering that somebody found "logging errors to STDERR" to be a "ceremony"
- deleted 10y ago
  [deleted]
- coredog64 10y ago
  The days of Perl CGI are a distant memory. More than that, it is a distraction. I'd be happier with the use of a parameterized test framework that lets you get to the point much more quickly.
- peruvian 10y ago
  In real life, I agree. But if I'm trying to solve an array sorting problem, why can't they just give me an array? LeetCode does it and it works fine. I get to focus on how to sort the array. The other commenter (natdempk) makes some good points though.
- jakobegger 10y ago
  If you work with a modern framework, chances are high you'll never actually read from STDIN. For example, I have no idea how I'd read from standard input in ObjC or Swift.
twic 10y ago
In most of the problems i've done, there's boilerplate code to read from standard input supplied as part of the problem. You just have to implement the algorithm. In the problems where it's not, yeah, it's annoying. But it's also the same one or two lines every time, so it's not a big deal.

go_go_ 10y ago

This is one of the reasons I'm eyeing management for long term career growth. I've learned that the problems given to sr. and jr. engineers are roughly the same, and that the interview process is biased towards jr.

rajeshmr 10y ago
I think the same way. Mostly biased towards jr. And management seems like a good option for long term career growth.
- imjustsaying 10y ago
  Isn't it a bad omen for any industry when the most realistic career advancement path is management?
  - bshimmin 10y ago
    Isn't that how most industries work, from flipping burgers to the legal profession? Why should tech be any different?
    - rajeshmr 10y ago
      True, also the industry prefers younger population coz they can burn more hours and are available for a cheaper than the experienced folks. Also, the industry somehow seems to stereotype a developer as some younger geeks. The stereotype works against experienced folks sometimes (not always).
  - rajeshmr 10y ago
    If we had a sane choice we would still stick to tech - tech is like the first love that is going through a rocky phase! I believe there is the "collective stupidity" problem in the tech industry where a new framework pops up almost everyday, a new language every now and then and the sheer volume of knowledge to accumulate to stay relevant is abysmally high! With the realities of life taking over, the path is inevitable to most senior people.

orsenthil 10y ago

> 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 entirely new and ship the code for the business. Those challenges are quite enormous with lots of unknowns compared to these programming contest problems where it is just preparation. 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.

nicksergeant 10y ago
On the flip side, now you have no idea if a developer is any good, because all they have to do is memorize a bunch of garbage interview algo techniques / questions.
- tspike 10y ago
  What is your preferred interviewing method?
  - tluyben2 10y ago
    For people with 5+ years of experience (like OP), I look at and talk about their portfolio; he did actually built stuff that runs in production, so let's see how that came to be. And show parts you have written and are proud of. We are probably in that interview because your skill set matches (somewhat) the problems we are trying to solve, hence your past projects will have similarities with our projects. That interests me. I can find out if you are a self starter, if you have any business sense by chance, management/tutor potential etc. That you can solve some complex thing in 5 minutes is of no interest to me at all, ever.
  - MaulingMonkey 10y ago
    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 delete through base pointer Extremely realistic - it's all stuff I've seen and fixed in the wild (this was for a non-entry gamedev job involving plenty of C++)

nickbauman 10y ago

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: they're really good at certain types of problems but suck at almost everything else. I end up cleaning up systems after these people all the time everywhere I encounter them in the workplace.

lprubin 10y ago
Exactly this. The hiring process cuts both ways. Unless you're desperate, you should also be evaluating your employer and the quickest way for me to walk away is to filter candidates through something like hackerrank rather then something much more applicable to what I'd actually be doing as a programmer at the company. It shows me a big disconnect between hiring and the day to day and gives me no indication on the skill level of the team I'll be working with.
tspike 10y ago
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.
- nickbauman 10y ago
  I can only hope you're right. The tone of the OP doesn't directly support either/or however.

ktRolster 10y ago

It's annoying, I agree, and sometimes on hackerrank the problems are miscalibrated, but the best way to handle it is to just do it. They aren't that hard, so spend a week or so getting your skill level up.

pweissbrod 10y ago

maybe what you should really hate is a company that adopts the en-vogue trend as the standards for recruitment. think about what that says about the team that passed their interview

rajeshmr 10y ago
Well said!

evilc0 10y ago

I completely agree with you. Measuring our skill based on HackerRank is completely bullshit. I'm 100% sure, every programmer-beginner (even every math student) can solve the problems on HackerRank but can't even deploy a application on server nor know how to deal with real customers nor read a build-script nor... (image a lot more things here)

EliRivers 10y ago

As an aside, I also dislike hackerrank; for me, it's the sheer ham-fisted ineptitude of some of the alleged learning exercises. Look at this mess: https://www.hackerrank.com/challenges/preprocessor-solution https://www.hackerrank.com/challenges/preprocessor-solution This purports to be teaching use of the preprocessor. It's horrific. It's someone's amusing "look at how you can create your own programming language by abusing the preprocessor" mess; fair enough, it's always fun to see someone do something this painful, but this is being genuinely presented as a preprocessor learning exercise. 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.

0xmohit 10y ago
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, the Universe and Everything.
- greenyoda 10y ago
  Which is why anyone who has experience programming in C would instead write: #define add(a, b) ((a) + (b))
  - 0xmohit 10y ago
    One may also do: add(x, foo(x)) Which is why anyone who has experience programming in C would use (an inline) function instead.

daveguy 10y ago

The important thing is not to ace the final result. The important thing is to communicate your thought process, identify bugs, talk about options in architecture and design, stay calm under pressure and keep a positive attitude even when asked to do something you think is silly. The interviewers know "this exact problem" is not generally applicable to their work. They are looking at how you interact with the problem. Projecting a bad attitude toward being asked to code on a whiteboard is the opposite of what you should do and misses the point entirely. Code golf and competition (right answer in min time) is not the point.

ojr 10y ago
you can't communicate your thought process on hackerrank or triplebyte it is a timed online test

nine_k 10y 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.

coredog64 10y ago
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.
- walshemj 10y ago
  Then you managers are poor I have only ever worked with one person who was totally unsuited for working in IT.
djhworld 10y ago
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.
raverbashing 10y ago
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.

rajeshmr 10y ago

I face this problem. I am into server side scripting and automation and this hardly involves algos and stuff. The problem doesn't seem to lie with hackerrank but with one-size-fits-all HR approach. I would also pin the blame on lack of understanding on the part of HR personnel (they seem to be the drivers behind recruitment drives) of how the tech landscape is.They need to educate themselves on what sorta interview process to be conducted for different profiles.

skybrian 10y ago
That seems... limiting. Are you sure you want to specialize that much, and rule out doing any programming that does require understanding something about algorithms?
- rajeshmr 10y ago
  I do know algorithms, it's just that I don't use it in my day to day activities. When confronted with an online challenge with time constraints I seem not to cope since I hardly use algos in my day to day automation it isn't right on top of my fingertips! Without time constraints I am able to solve the problems. Timed Algo assessments are very similar to exams u write in universities.. u need to keep practicing to complete those assessments in time and get a "pass mark".

maxaf 10y ago

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 were employed by the same company. This takes away most of the stress of interviewing, which I know via candidate surveys. My advice would be to steer clear from employers who use a soulless cookie cutter process that makes people feel like a commodity. This is how you'll also be treated during daily interactions and in conversations about your career development. Don't be under any illusion that you'll be able to find yourself on the right side of such a situation.

samstave 10y ago
>"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 knowledge of tech/lang X.... and then on-top of that, judge their fit for working well in the team! only ask that when they come back from a takehome issue, that they say exactly how they solved it: "I had to call my buddy over at BigCorp and say, hey dont tell me the answer - but lead me to where I might figure out how to solve this problem" OR "Hey joe, I did this - but i am not sure how efficient it is - did you do something similar?" Tell them to get a slack channel of their peers to help them succeed. 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.
- emilburzo 10y ago
  > 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.

d23 10y ago

Recruiting and hiring are garbage right now in the industry. Part of the problem is easy to recognize -- idiots designing interviews. This is where the puzzle crap comes from, as well as theoretical stuff that's far removed from the day to day of what a person will be doing. The other problem is that the people who could be designing better interviews aren't stepping up. There are plenty of intelligent people who aren't 1) taking the time and effort to introspect and think about why they are effective as people and 2) taking those insights and translating them into an interview process that selects for important traits in simple, reproducible ways. It's bizarre. A job could require years of experience with linux, programming, and networking, all of which could be tested with a multiple-choice style test to get a sense of where a candidate stands. Instead, we look at their resume, check off that they have our requirements buried somewhere in the forest of buzzwords, and then move onto whether someone can finger-paint their freshman year CS lectures onto a whiteboard. Then when we end up hiring a completely ineffective person who spent their entire time trying to game the interview system, we are surprised, even though we've been selecting for that kind of person all along.

IndianAstronaut 10y ago
Another thing missing from interviews is being able to find various talents in engineers for the diversity of the engineers out there. Are they good at finding corner cases, are they creative with product design, are they good communicators with a non technical audience.
yitchelle 10y ago
> This is where the puzzle crap comes from, as well as theoretical stuff that's far removed from the day to day of what a person will be doing. I find looking through past project work is one of the best indicators of their ability. However I have found this to be extremely difficult to get. NDA restrictions of their previous employers is one major restrictions, or he is transitioning from a different domain or career path.

samstave 10y ago

As an aside.... I find it ironic that almost all companies talk about "culture, family, work-life-balance" yet they treat recruiting as robot selection.... IQ Hazing is a good way to put it... but how do you measure, "Do I even want to fucking work with these people/this company???"

eyelidlessness 10y ago

> I'm an experienced developer with 5 years of thorough product experience in the domain. I'd completely appreciate the importance if the role actually did involve trying to eek out efficiency in a distributed system with high throughput... but 9 times out of 10 it's boilerplate business logic. This is what I don't understand about software engineer hiring. They are ignoring important criteria about fit for the actual job, and focusing on criteria that is either orthogonal or completely irrelevant. It's worthwhile to ask in these situations if the exercise is representative of work you'd be doing. It almost never is, but they tend to excuse it as... > it normalises the application process against prejudice But does it? By ignoring the actual criteria relevant to the job, they're dumping qualified people who don't do well with the hazing, and delaying evaluation of everyone else until after they're hired. That evaluation tends to be a lot less objective, because "hiring is expensive"; it selects for people who do well with the hazing, and reproduces the problem for the next round.

bunderbunder 10y ago
> This is what I don't understand about software engineer hiring. They are ignoring important criteria about fit for the actual job, and focusing on criteria that is either orthogonal or completely irrelevant. Oftentimes, the people actually designing the hiring process have an imperfect understanding of what work software engineers actually do. They ask the software engineers for input, but optimizing the hiring process to be orthogonal a software engineer's core work responsibilities, so they aren't necessarily going to give ideal advice.

git-pull 10y ago

For their own expedience. It's an employer's market. It costs 2.5k/yr to keep an SO posting up and get thousands of resumes in your inbox. I'd also say a fair share of those in Who's Hiring on HN aren't in dire need of filling seats, but just trying to see how far people with fling themselves through the mazes. Blissfully unaware they're not the only startup and have no way of offering the stability of a large company. At one of the places I've seen, we didn't read every resume. We overlooked mountains of talent and shot ourselves in the foot. Instead of hiring coders that had their heart in the right place, we hired streetwise careerists that put their own interests before the team. But they could do palindromes, fizzbuzz, and whiteboard data structures and algorithms. But when we wanted them to do something generalist or in another language, they'd refuse. One even went so far as saying if they could program X in Y editor, they'd just leave the job. What use is passing all these tests if you're totally inflexible? We also snubbed people enthusiastically espoused the startup gumption and idea of building, but didn't cope well with the white boarding we thrown at them. Those whose heart was in teamwork and open source, we overlooked ignorantly, while continually putting up walls to see who finally gets past all of them. There is some toxic cultural thing amidst in startups of insularity and smugness. If I could go back, I'd say screw it with the whiteboard games, come freelance with us for a week. That way I can gauge your temperament, how you work with teammates, your technical skills, etc. in a realistic setting. And if someone asks for a code sample, and you already have projects on GitHub or your portfolio, don't be afraid to redirect them to that instead. If they don't look, assume the employer is not serious about filling the spot, but just putting in the least effort themselves to see how many hoops people jump. It's not you OP / other programmers. If an employer doesn't bother to give you a phone call to talk to you as a human being, maybe they're not so eager to have a position filled. Don't let it effect your self-worth. Always be coding. Don't be afraid to stick your head out there at a meetup and shake some hands, you'll be surprised how much more decency you court when you represent you're a human being, not another resume in a stack of thousands.

bunderbunder 10y ago
"Come freelance with us for a week" seems even worse to me. For starters, there is a very small and fairly specific subset of the population that can afford to carve out a whole week for an extended interview, even if you do pay them for their time.

k2xl 10y ago

Sort of surprised to see most of the comments on here actually defending the companies that put so much weight on these types of tests. I think many people assume that interviewers are looking for "thought process" but from my experience as a hiring manager for 6 years, in reality you'll find that most are just looking to "gotch-ya" the candidate. Many interviewers seem to enjoy making a candidate "sweat" as some source of pride. Again, not saying everyone does this, but often times programmer interviewers believe that the harder and more obscure a programming question is the better. We should all agree that coding tests are helpful in assessing a candidate's programming capabilities, but not all coding tests are equal. From my experience, bad coding tests that have little relation to whether a candidate will do a good job are these arbitrary ones. For example: * Implement a merge/quick/radixx sort algorithm that you maybe did 10 years ago in college and have never had to do since. * Implement a linked list/hashmap/some other random data structure in Java even though you would never write on yourself. * Write a program to determine whether a string is a palindrome. * Implement an algorithm to solve this random problem from Project Euler Ones that have been worked better attempt to be comparable to what they actually might do in the company: * FizzBuzz - (While controversial, this helps weed out people who just don't know how to code) * Build a JSON REST API in whatever language you want to manage groceries in a shopping cart. * Write a web scraper in whatever language you want to count the most popular words on a website * Here is a random UI framework that you have never used, use whatever documentation you can find on the web and write a To Do list application with it. Again, YMMV, and depending on your domain certain questions make more sense to ask than others. If you're interviewing as a researcher for Google/Amazon/IBM/Microsoft, then you actually might need to know how to implement some random sorting algorithm because it may be what you will need to implement it in some new SDK/library. But I don't believe that for most companies this makes sense. If you are a hiring manager, ask yourself this: If you had to run one of your current (positive) team members through your current interview process, would they make it through? Would they say they had a positive interview experience?

bostik 10y ago
> I think many people assume that interviewers are looking for "thought process" but from my experience as a hiring manager for 6 years, in reality you'll find that most are just looking to "gotch-ya" the candidate. Many interviewers seem to enjoy making a candidate "sweat" as some source of pride. What you describe is a horrible approach to interviewing, and points towards dysfunction more than anything else. In my opinion, the second most appealing non-technical character trait for an engineer is empathy. (Curiosity being #1.) If you have an interviewer who goes on a power trip and actively tries to abuse a candidate, what does that tell you about their company? Everything is PR, and how we interview engineers tells a lot about how we deal with each other. Would you like to work in a place where being nasty is considered normal - or even desirable?

hw 10y ago

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 world - doing actual work and building apps and contributing to the team instead of writing the next (insert your fav tricky algorithm question here) solver. It's unfortunate that while many companies that are hiring are just run-of-the-mill SaaS and apps companies that don't require you as an engineer to use algorithms or DP on a daily basis (or even ever), you still see algorithm heavy interviews at these companies. On Hackerrank, I don't necessarily hate it as a tool, but just the questions that get asked through it. I don't like that it automates an interview process to a certain extent, as a candidate's potential and skills and experience and fit in the team can't exactly be measured via an automated process but requires actual human to human interaction. If a company rejects you on the basis of failing a Hackerrank question and hasn't even talked to you, you're better off working for a different company.

0xmohit 10y ago
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.
- jedmeyers 10y ago
  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.

djhworld 10y ago

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 < 10 minutes? Or do they present their medical credentials, and get interviewed on their bedside manner, their ability to work in a team (if applicable), anecdotes about their past experiences etc?

llamaz 10y ago
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.
lloyd-christmas 10y ago
Med school is difficult. An internship is difficult. A fellowship program is difficult. Undergraduate degrees are a rubber stamp, CS included. There are 20k oncologists across all fields of oncology within the US. That's also about the number of engineers Google employs. Most other industries we like to compare ourselves to are leagues above ours in individual merit. My father is an oncologist, and I'm reasonably confident he has some familiarity with every genitourinary oncologist in North America, Australia, and Europe. More importantly, he's on a first name basis with all of their educators. When he needs to hire a new doctor, he doesn't post an ad on health stack exchange. He makes an offer to a specific individual who he already knows. One thing that we as an industry fail to understand is that we're not special. We desperately claw to it in these conversations. I'm willing to admit it: I'm easily replaceable. Very few of us have any name recognition that exists in other fields. I worked in finance for half a decade before moving to software. When I'd go to interview, people already knew who I was because of the basic human interaction I had as part of my job. When I walk into the door of my next interview, the only thing people know about me is what's on my resume/blog/stack overflow answers. Personally, I find technical interviews to be a cheap and easy filter. You may not always get the best person from your pool of applicants, but you get someone that's better than most of them. The marginal benefit of one vs. the other is rarely meaningful. OP complained about having to do this, but some of the other applicants might have found it difficult. Sounds like it was successful.

jacques_chester 10y ago

Here's how I was assessed for my job at Pivotal: 1. I did a simple tech screen (the RPI). 1 hour. My interviewer had a laptop and asked me questions about what to do next in the scenario. 2. Hey, come pair with this engineer on this real code on a real project on a real task. 3. How about lunch? 4. Hey, let's have you pair with this other engineer on real code on a real project on a real task. 5. Get offered a job on my way out the door. I know from feedback that we don't always do this right, that we sometimes drop the ball, that many people find the RPI or the pairing to be frustrating, intimidating, or uncomfortable. Most importantly, many people find that they just don't want to work the way we prefer. Which is good! It saves them the unhappiness of committing to a situation that won't enjoy. But the core insight is: the best way to see if someone can work alongside us on a real problem is to ask them to come in to work alongside us on a real problem. It's the best proxy we have short of hiring you. When it's available as an option to do this, I don't understand why anyone would choose a less accurate proxy.

0xmohit 10y ago
It's also a fantastic way to see how one thinks, one's problem solving approach, debugging skills and the like.
- jacques_chester 10y ago
  It is! I hasten to add that it isn't perfect. We hire across the intro-extraversion spectrum, but there's an ongoing concern that we're biased towards extraverts. Especially in Labs, which is the consulting wing. Another problem is that many candidates are just plain nervous. We do our best to set people at ease and to be upfront that there's no right or wrong or trick answers. But interviewing is just scary. I expected to fail and so felt no pressure -- had I felt that more was on the line, maybe I'd have done worse. The third -- this is a very common negative opinion -- is the argument that we don't give candidates a fair opportunity to show their expertise. We will usually try to assign one project where their résumé claims expertise and another one that they're unfamiliar with. The former to take a sounding of their expertise, the second to get a feeling for their approach to the unknown. It's not always possible to do this, simply because it's a vast field and candidates come with very varied backgrounds. And those candidates who are declined often feel that we've denied them a fair chance by throwing them into an unfamiliar technology. These are all fair criticisms. My best answer is: we are not trying to trick or exclude anyone upfront. Ultimately the hiring decision is made by future peers, so we want to be fair but firm. Hiring is just hard.

quantumhobbit 10y ago

I don't mind algorithms and brain teasers if they are presented well. As in the interviewer makes it clear they aren't looking for a single right answer but want observe how you solve a problem. Plus I enjoy a good puzzle. My problem with hackerrank is that the problem statements are often unclear and have artificially short deadlines. I feel like it forces my to use unreadable and sloppy coding to just get any solution out the door before the timer runs out.

throwaway_415 10y ago

Just to add two points that bother me the most: 1. It doesn't actually test my ability. Most of the time there is a stackoverflow solution and I'm going to just look it up and regurgitate it. I can't remember where I read this but allegedly it took Knuth a day of thinking to come up with the most optimal solution for one of the presented challenges (it was either the maximum subarray sum or stock sell problem). 2. It's all very well preparing for these interviews at my age (under 30, no responsibilities or family, generous severance from my previous employer), however, what happens 10 years down the line with responsibilities and hungry mouths to feed.

0xmohit 10y ago

Not many within a team that is hiring either have the time or skills to assess candidates. Employers are looking for a magic solution to fulfill their staffing needs. Companies such as Hackerrank have thereby managed to convince employers that they have the solution to all the hiring problems. Essentially a magic wand which would enable them to hire Einsteins.

newjobseeker 10y ago

I'm going through this right now. I've taken some time (1+ years) off and do admit to being rusty. However, I've dedicated time to studying and I'm not getting past some technical phone screens because of these algorithms-heavy questions. I do well enough on them yet are passed over. I thought the market was "hot" and this would be relatively straightforward, but it has been anything but easy. I'm also starting to wonder if there are other factors at play (ageism, female).

fixxer 10y ago

These things are really just filters. Due to the legal aspects of hiring/recruiting, especially at large companies, these exercises are par for the course. Once you're in a large company, firing can be very difficult, so I'm all for filters. Personally, after having taken many of these tests myself, if you're having even minor problems, that is a huge red flag for me. They're really just binary filters on basic skill level.

walshemj 10y ago
With the USA's at will and limited worker protection you must be kidding about how hard it is to fire people
- fixxer 10y ago
  In my experience, it is very hard to fire people if they are simply incompetent. You can fire them for mistakes, but just sucking at one's job is this awkward grey area where you wrestle with HR and they usually suggest investing in training, etc. That is fine and good, but when I got a deadline, I'm not going to tow deadwood.

spitfire 10y ago

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 them as proxies. Using IQ is effectively illegal[2] in the US, so you'll have to find a test that acts as a good proxy. - Work sample test. NOT HAZING! As close as possible to the actual work they'd be doing. Try to make it apples-to-apples comparison across candidates. Also, try and make accomidations for candidates not knowing your company shibboleth. - Integrity. The first two won't matter if you hire dishonest people or politicians. There are existing tests available for this, you can purchase for < $50 per use. This alone will get you > 65% hit rate [1], and can be done inside of three hours. There's no need for day long (or multi-day) gladiator style gauntlets. [1] http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%20Validity%20and%20Utility%20Psychological%20Bulletin.pdf http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%... [2] The effective illegality comes from IQ tests disadvantaging certain minority groups.

Houshalter 10y ago
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.
thedufer 10y ago
> Using IQ is effectively illegal[2] in the US, so you'll have to find a test that acts as a good proxy. You've posted this before and been called out on it. Please stop spreading misinformation. There is nothing special about IQ tests specifically. Any proxy test will have exactly the same legal ramifications. As long as you can show that the results of that test are relevant to job performance, it is fine. Whether it is labeled an "IQ test" is irrelevant.

deleted 10y ago

[deleted]

inverse_pi 10y ago

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.

amacneil 10y ago

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.

Houshalter 10y ago

What about for people with no experience or education? I'd love the opportunity to prove myself through testing rather than relying on credentials I don't have.

siliconc0w 10y ago

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.

jandrewrogers 10y ago

It could be worse. My personal recruiting peeve is what I call the "Dunning-Kruger interview", where they ask algorithm questions they don't understand and don't even realize that fact. It is unfortunately common, and made doubly worse when it is plainly my area of expertise and the reason I was recruited in the first place. More than once, I've been recruited by executives at Famous Tech Company to run major new initiatives involving vast volumes of spatially organized data, since my expertise in that area is well known, but there is a technical diligence step where I am grilled on spatial algorithms by a shockingly ignorant (e.g. doesn't understand R-trees) Principal Engineer or similar who actually believes no one can know more about the space than they do. (If that was the case, they wouldn't be trying to recruit me.) If an interviewer wants to test my expertise, they better be able to have a substantive discussion on the subject matter and understand the limits of their own expertise. I view algorithm gotcha games as disrespectful of an experienced software engineer's expertise generally. I like to turn it into a substantial discussion about the algorithm class generally; if the interviewer is incapable of having a substantial unscripted discussion about said algorithms, it is a red flag and they have no business asking those kinds of questions. These days, I just walk away from an opportunity when this kind of nonsense happens.

greglindahl 10y ago
... maybe the point of putting you in with the shockingly ignorant Principal Engineer was to figure out if you could work with them?
- jandrewrogers 10y ago
  Heh, possibly, but in practice it usually appears to stem from complete disinterest -- it is an assignment and they do minimal background investigation. I go along with it, but in one extreme case I had a PE-type flatly accuse me of not understanding the theoretical details of a particular algorithm, being unaware that I invented it (and I never mentioned that). When it gets to that point, it is a lost cause. Some computer science domains are worse than others. Spatial is particularly bad because very few computer scientists realize the theoretical foundations of spatial data structures are completely different than the more ordinary ones they are familiar with -- their intuitions don't apply.

guessmyname 10y ago

I have +6 years of work experience as a developer and for the last two months I have had +36 pre-selection interviews via HackerRank with a wide range of small to medium sized companies. I am not ashamed to say that I have failed every single one of them, but I have to recognize that I have learned more things during the last couple of weeks about algorithms, data structures and prioritization than in most of my career. This week I was invited by an in-house recruiter from one of the "Big 4" to resolve two coding problems via HackerRank in 120 minutes, plus a third exercise asking about the time and space complexity of my solution. I am 99% sure that I will fail this pre-selection too, but I really do not care, the more I practice now the more opportunities I will have next time. I have talked with people who were hired by Google, Amazon, Booking.com after 8-12 months being unemployed, so — in my case — two months is certainly nothing, I can use the next six months to train myself and maybe next year one of these companies will extend an offer and then I will forget about all this hiring madness.

markbnj 10y ago

Organizations seek out formulaic ways of qualifying candidates because actually assessing an individual's talent and personality takes time and effort, and is a significant investment. The pressure to streamline the process grows as the company grows and hiring becomes a more frequent thing. It's one of the main reasons I like working for small companies. As a case in point I'll describe the process that led to my current position. After the application and a brief phone call I was given a take-home project with a one week deadline. The project was directly related to what the company does, and was interesting and fun to do. I submitted a pull request in four days. The pr was reviewed by their engineering team and they all voted to move me forward. The next step was a work along day for which I was paid. These are typically done in person but for various reasons on both sides we did it remotely. The entire engineering team participated in a dedicated slack channel as we walked through my homework project, suggested and implemented changes, joked and in general had a good time. At the end of the day I said my goodbyes and an hour later the recruiter called to tell me they were preparing an offer. The advantages of this process should be readily apparent. By the time my first day arrived we already knew we'd get along, approached work in compatible ways, etc. The costs of the process should also be readily apparent, and it would probably be really hard for a larger company to do things this way.

_RPM 10y ago

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.

retreatguru 10y ago
I agree, not sure why this was flagged. The title is clickbait, but it seems this guy genuinely does hate hackerrank. fair enough.
- _RPM 10y ago
  Because its bad PR for hacker rank. That's why it was flagged.
  - retreatguru 10y ago
    Ironically often any PR is good PR. So many people who otherwise would not hear about hackerrank will now hear about it and many will use it regardless.
throwaway_415 10y ago
Possibly because I'm brand new (I'm not, I'm a very long time lurker and one time failed YC applicant).
dang 10y ago
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.

noir_lord 10y ago

I just wouldn't apply anywhere that does that, it's a ridiculous way of testing a developers fit for the average role and a strong warning indicator that it'd be somewhere not to work.

hvd 10y ago

if you don't like hacker rank. suggest a technical phone screen over a shared notebook or a homework problem as an alternative. See how that works.

StreamBright 10y ago

Our hiring process uses only homework. We give you a problem to solve, a single Java file to do code review on and some database problems that you have to solve with MongoDB. Based on how well you do we go for a phone interview and if it goes well we bring you in for an onsite interview. I tried HackerRank a while back but it does not give us too much value. The competition going on it can be fun for programmers who like challenges like that but it has almost zero indication how well you are going to do in a production environment working on a mission critical system with a team and where your code is running on any infrastructure. Using it as a hiring tool is fundamentally flawed in my opinion.

jsonau 10y ago

@OP: You sound almost exactly like me. I have not done any interviews for a bit more than 5 years. I think the what really can be improved is to test us in a more familiar and friendly environment. I have to spend time on handling time-pressure, and fix/adapt with my thinking habits. ## Coding Problems: I do think coding challenges(algorithmic) has merits, but I think there are two factor that really hinders a interviewee's performances: - time limit - require an unfamiliar algorithm Time limit is obviously needed in a test, but problem solving in real life is never instant unless it's done before. Nevertheless everyone have their own pace. I have to dedicate hours each day to train myself to adjust my brain to act quicker yet calm for these algorithmic questions. Sometimes my initial solution in my mind turns out to be the best, but I discard it. Nevertheless if one is stuck, the time limit just makes it worst. I'm also known to be the slowest in turn-based board game -- I have high win rates though! ## Possible Solution? * Allow interviewee pick from a pool of equally-difficult-challenges to solve (within a minute or two). This can solves the "obscure algorithm" or "trick" question. This also helps the time-limit problem as the interviewee WILL interpret the question twice in two different VIBES (with and without time pressure) Even choosing 1 out of 2 would dramatically reduce nervousness and time pressure.

passiveincomelg 10y ago

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.

sanketsaurav 10y ago

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.

rl1987 10y ago

There is no shortage of reasonably competent software developers in USA and West Europe. The very existence of things like Codility and HackerRank proves that. However, there is significant shortage of sanity and common sense in the culture of developer hiring.