If there are separate tutorials for how to "Crack the Coding Interview", maybe coding interviews do not accurately select for coding skill.
And if it were 100% about preparation -- if preparation could land anyone any job they wanted -- then the interviews would be mostly worthless (other than perhaps assessing how much work someone is willing to put in).
The reality is somewhere in between: Preparation helps someone perform at their best, but it will not land anyone any job they want. This is why tech companies actually encourage preparation -- it reduces the number of good candidates who get rejected.
Note that this isn't really unique to coding interviews. People prepare for ALL types of interviews, so it's revealing the same flaw in all of them.
HackerRank is a symptom of the terrible interview cult that is pervasive in our industry which is so extremely guarded against the fabled false positive hire. It is designed with absolute certainty that no one is qualified for any job unless they are some silly notion of a 10x engineer or "hacker" while claiming there is an engineering shortage. It allows us to opine about how terrible impostor syndrome is while simultaneously engendering it in others through these interview practices. It allows us to write off people with experience who are further out from college (and therefore older) or never even went under the guise of algorithmic knowledge requirements without admitting ageism.
As to other industries, I have little direct experience. I know that my friends and family (none of which are in tech) have been on interviews that are humane and conversational as opposed to the inquisition our industry supports. They have all been aghast at what I've been going through.
A. Don't make the interviews so hard that they require multiple months of preparation. You can be prepared for the google interview by simply having taken an algorithms course and studying for 2 or 3 weeks.
B. Make sure the people you hire are good communicators and are a good culture fit.
C. Try to make your workforce diverse.
These companies make bank from both sides (the person interviewing who is cramming on their material, and the employer), and leave out important things like how well you work with teams, how fast you adapt to new frameworks, or how maintainable your code base is.
I guess it is no surprise that another of their "featured" blog posts talks in extremely glowing terms about someone for coding for 24 hours without any sleep. (http://blog.hackerrank.com/recap-how-mimino-solved-78-projec...).
By having a filter, it allows a company to evaluate a lot more people and not rely entirely on the resume (which might not do a good job of representing your skills). Presumably, they are already doing these same style of coding+algorithm questions later on in the process, so this is just weeding out people who clearly wouldn't pass (and identifying people who would unexpectedly pass). Not a bad thing.
If a company is using it as total replacement for the hiring process then, yeah, that's broken. They won't be able to evaluate team work and a bunch of other things.
This is true only if your coding/algorithm interview process is the exact same as HackerRank. Alternately (like they do at the place I work at), if your coding interview is conducted in person and relies upon you correctly describing a thought process rather than coming up with the correct code snippet, it's an awful replacement.
Yes, the fact that in-person interviews involve some back-and-forth conversation makes the HackerRank ones slightly less predictive. But slightly less predictive doesn't mean "awful."
It's worth noting that on HackerRank, candidates can see how they're performing against the test cases. So when people don't perform well, it's not that they made some silly mistake or misinterpreted the problem. It's because they truly weren't able to get something more optimal or more correct.
Companies can set the bar wherever they want. There are times when a company sets a bar too high. You certainly can implement HackerRank in a good way. You can also implement it in a bad way.
Save the tough questions for the onsite interview, where an interviewer can subjectively make judgments about their performance.
You don't necessarily demand perfection on this test though.
One mistake that companies make is that they think they want to set a lower bar, so they make the questions easy. But then, in order to distinguish candidates, they basically require perfection. Now, a simple mistake can "fail" a good candidate.
It's better if they make the questions harder, but just don't require perfection.
You can see how you do against test cases in aggregate. You are given a few examples, the rest are hidden from you. A completely arbitrary and vindictive restriction.
I think what you're really trying to say is that blind filtering is bad (okay, you said this part explicitly) and you think that HackerRank is a blind filter. Unfortunately, this is pretty obviously not true. HackerRank uses quite a bit of data. Arguments that HackerRank is using the wrong data, or using what data it has poorly, would make a lot more sense than what you've said so far.
Can you point me to the part of the HackerRank website where they ask people (not businesses) to pay them money?
A slightly weaker version of that argument is that having a vast base of signed-up users and data about their challenges is still making bank out of the efforts of individual users, but clearly not as bad as requiring you to pay for this tutorial.
I actually didn't even notice this conflict of interest. It would line up exactly with how such an awful class of product has gotten so popular. I've been subjected to HackerRank tests before, along with a few competitor's products. They are universally demeaning, insulting, infuriating, and useless as an indicator of skill.
As if for the same crop of... for want of a better term... "kids" who had the whole stack-ranking and "human beings are infinitely measurable and weighable" ethos so relentlessly and successfully drilled into them from pre-K up through graduate school -- there's not even a question of jacking up and scaling out that same system out into the professional working sphere. It's just the way universe works.
And so of course getting a leg up and "making it" means cramming one's brains out for however many months as necessary in order to graze whatever "bar" they set because... that's just what learning is, right?
(or if you want to be mean, take it, answer every question with a variant of 'this is dumb' and then email the company saying they just wasted their money on these systems)
I've been looking for full time employment for over 6 months now, doing contracting to make ends meet and to stay involved in the industry. I started out doing the tests, putting lots of effort into the insipid take home exams, and so on. It amounted to absolutely nothing. I'd get invited on site, get tortured with a whiteboard for 6 hours, and get no offer.
Meanwhile, contract "interviews" have been "What have you done at your previous jobs?", "How can you help us do $THING", and finally "What's your rate?". They have, unlike FT interviewers, understood that I am telling the truth about what I have done, what I can do, and how I do it, and so didn't require a college test to prove it.
The only alternative is to be at least -somewhat- compromising -- as I don't mind these tests too much, if they're on the short and sweet side (up to 90 min timed, or 3-4 hours untimed). But once you've decided what your limit is, hold to it. "I'm sorry, but I've done enough of these already -- sometimes without getting any response at all from the company, even though I felt pretty confident my solution was at least ballpark correct -- so unfortunately I can't justify the time investment for your drippingly pretentious mandatory 4-hour HackerRank hazing session."
(Same goes for ridiculously over-hard and/or over-rushed algorithm questions which in realistic terms almost no one is able to genuinely "solve" in the time provided -- unless they crammed and/or did them very shortly before. Just sit back and assess the situation for 5 minutes before jumping in. And if, heaven forbid, you don't think you'll be able to crank out the flawless the solution they'll undoubtedly expect in the next 35 minutes -- just say, "I'm sorry, but I done challenges like these before and I just don't they're realistic problems to ask people to solve on the spot. So I'll have to pass.")
Of course you don't have to use the exact phrases "drippingly pretentious" and "mandatory hazing session." But at least you're giving them a qualified rejection (instead of "Neah, I'm just too cool for your shit.") Which they'll also almost certainly decide to pass on you for. But if so, then at least you've managed to hold your ground, and keep your head up.
And who knows, maybe at some point these companies will start looking at the response data on these poorly considered "challenge" tasks -- and will move on to some other filtering fad.
But given that it's most likely the result of junior hiring managers giving marching orders to junior engineers (i.e. the people conducting the screening) who just don't know any better than to say "no" to such a silly and insulting request to make of incoming candidates... the depth and reach of this annoying fad becomes less surprising.
On the other hand it would be idiotic to expect people to be able to code in IDE XYZ (whether it has vi and emacs mode or not).
First, it's much harder to scale in a consistent way.
Second, and more importantly, you also evaluate how they code right now, on these specific technologies, not how well they would code with a bit of training.
Think about it: There are a ton of new college grads who are better software engineers (or would be, with 6 months) than people with 20 years of experience. But a person with 20 years of experience who knows that technology will perform better in an immediate sense than the new grad.
No interviews are perfect.
Citation? How does having fresh recollection of algorithms that you will rarely if ever use outside of interviews make someone a better software engineer?
I wasn't saying that new grads are, on average, better than experienced hires. I was just saying that experience is not everything.
An experienced hire will outperform a new grad on a "build this project in 3 hours" test. But the new grad might actually be a fundamentally better engineer - they might be smarter, more careful, etc. Given 3 - 6 months of training, the new grad might actually make better technical decisions.
Obviously, the reverse can also happen: the experienced hire might be not only more knowledgable, but also smarter, more careful, etc.
The problem with the "build a project in 3 hours" test is that it weights experience and knowledge so heavily that you end up eliminating people who could be great, with a little bit of training.
Again, a new grad could also be a fundamentally terrible software engineer (there are fundamentally terrible software engineers with experience and with no experience). And in 20 years, they'll be a terrible software engineer with 20 years of knowledge and experience. They might be able to build a 3-hour project better than some smart inexperienced coder but I'd still rather hire the smart inexperienced coder (assuming I have some time to train them).
Ultimately, ALL hiring processes are flawed.
A hiring process that acts as if years of experience mean nothing and which reduces your career to a score on a web page generated by a terrible constructed test is especially flawed and inhumane.
The companies that sell these products are profiting from hurting people.
Hahaha, please tell me another one Mr. Trump.
> A hiring process that acts as if years of experience mean nothing and which reduces your career to a score on a web page generated by a terrible constructed test is especially flawed and inhumane.
Being old is not an indicator of success.
You seriously seem to live in some wonderland where the quality of a candidate just magically appears out of thin air.
I want candidates to have studied. Studying isn't gaming. Studying is being smart. I want candidates that studied. Those that didn't I don't want. They don't want the job badly enough.
I routinely test older candidates who can't program anywhere outside of the little box they made for themselves, and freak out when they see a programming language that isn't the one they've used for the last 20 years. Is that inhumane?
Gayle is awesome. Cracking the Code Interview is a really great book, and I credit it for getting me through some of my interviews. Everyone here poking at her are people shooting the messenger for delivering the inconvenient truth.
> Being old is not an indicator of success.
I didn't say it was. A history of success is an indicator of being successful though.
> You seriously seem to live in some wonderland where the quality of a candidate just magically appears out of thin air.
You seem to love in a wonderland where a candidate's aptitude can magically get turned into a score on HackerRank.
> They don't want the job badly enough.
Yeah, fuck them for not wanting to waste time on your startup that will likely bomb in a year. How dare these people want a personal life.
> I routinely test older candidates who can't program anywhere outside of the little box they made for themselves, and freak out when they see a programming language that isn't the one they've used for the last 20 years. Is that inhumane?
And I've met hotshot new grads who think they're the best thing since static typing, yet can't benefit from years of experience in how software is made in the real world.
> Gayle is awesome. Cracking the Code Interview is a really great book, and I credit it for getting me through some of my interviews. Everyone here poking at her are people shooting the messenger for delivering the inconvenient truth.
I only now realized the user who I am going back and forth with elsewhere in this thread was the author of these books. I am pointing out the flaws in these types of interviews and how they are very overvalued. The book's ability to get you through interviews means nothing about how those interviews select for people who can do the job, only that the book was designed to help you get through interviews.
I also don't think companies should dismiss years of experience. That is valuable. It's not everything -- you can, of course, have bad but experienced engineers. But experience is certainly valuable. It makes you a better engineer.
If a company entirely relies on coding interviews, they are making a mistake.
This is pretty simple.
Experience makes someone a better software engineer. Smartness also makes someone a better software engineer.
Some experienced people are smart. Some are not. Some inexperienced people are smart. Some are not.
All else being equal, I'd prefer to hire experienced over inexperienced, and smart over dumb. But, sometimes, all else isn't equal.
Given two candidates (P = smart but inexperienced vs Q = dumb but experienced), who would you rather hire?
I, personally, would rather hire P. I can train P and turn them into a pretty good software engineer -- and P will only get better with time.
A process that is a "build this project in 3 hours" test will favor Q. If you prefer Q over P, then that's a great process to have.
If you prefer P over Q, then this probably isn't the right process for you. You might do better with the whiteboard coding/algorithms process -- or some mix of different things.
And, you know, that's okay. All interview processes are flawed. A company should pick one that is the least flawed for their situation, be aware of the weaknesses of their process, and do what they can to mitigate it.
Tech companies are generally aware that one of the weaknesses of the algorithm-focus is that good people sometimes do poorly do to lack of preparation, and that's why they encourage preparation.
There are better and worse candidates in either camp. I developed software professionally for about two years before graduated. Is it 20 years? Nope. Conversely, it's more experience than many college grads. Working with super talented individuals with an express focus of learning/improving also gave me a hell of a lot more than "a fresh recollection of algorithms."
But that said, you always need to gear your interview to the hiring goals. Hiring someone with no experience is a completely different effort than hiring an experienced dev or lead.
It also certainly depends on the environment and task.