Oh, totally. If interviews were a perfect science, and perfectly measured ability, then you wouldn't need to prepare for them at all. You're absolutely right there.

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.

In my experience over the past year, programmer interviews are almost all the way towards the "preparation" (learning to interview, not learning to do the job) end of the scale, with a unhealthy doses of sadism and elitism. I've rarely been asked anything that has something meaningful to do with my abilities as an engineer, only demeaning HackerRank style tests that check only for algorithmic academics knowledge, insulting take-home exams that ignore existing code and industry experience, and torturous whiteboard sessions that select for nothing except ability to withstand day-long in-person inquisitions.

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.

I'd guess as an alternative to the "demeaning" HackerRank style tests which are purely meritocratic and allow smaller companies to interview large amounts of people you would prefer nepotism and only hiring and interviewing people with high GPAs from expensive schools?

The problem with meritocracy by standardized testing is eventually you reach Eastern/Southern Asian extremes with cram school culture of people endlessly drilling for tests. It's possible to rotely memorize strategies for applying algorithms until you excel at HackerRank type tests. By then you're just interviewing for candidates who spent the most to enter the most expensive boot camps.

Which is why you

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.

That's a strawman if I ever saw one. He never said anything like this.

He didn't provide any alternative and what I described is the status quo for companies outside of software engineering.

I have no idea why people who otherwise are against practices like stack ranking think that companies like "Hacker"Rank which assign you a score based on a set of simplistic algorithm are a good idea. If you are a manager and your company uses HackerRank as a hiring filter, I request you to take a good, hard second look at it – specially if you lament that you are unable to find any developers.

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...).

You're right -- HackerRank does leave out those things. It's a filter, not a replacement for the entire interview process.

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.

> so this is just weeding out people who clearly wouldn't pass

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.

It depends on where you put the bar and how challenging your questions are on each side.

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.

Agreed. HackerRank works great as an 'initial' filter. The way to use it correctly is to ask people a couple fairly easy questions, because if they can't pass the easy stuff, then you shouldn't waste their time with a full onsite. A person who is at least moderately capable, shouldn't at all struggle with your initial filter.

Save the tough questions for the onsite interview, where an interviewer can subjectively make judgments about their performance.

Or, ask two questions, where (on at least one) it's fairly easy to get an inefficient solution, but requires more thought to get a more efficient one.

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.

Oh god I know what you mean.

> It's worth noting that on HackerRank, candidates can see how they're performing against the test cases.

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.

For filter fun, try Googling "photo filters". Filters are generally bad, unless you actually want a biased output.

The only two alternatives to not filtering candidates are to hire every candidate or not hire anyone. How could these possibly be better?

Yes, not filtering is good, interviewing is good, hiring qualified candidates is good, not insulting senior candidates is good, blind filtering is bad.

Interviewing _is_ a filter. Each step where you eliminate candidates is a filter; that's what that word means.

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.

"Make bank from both sides"

Can you point me to the part of the HackerRank website where they ask people (not businesses) to pay them money?

I am sorry -- since Gayle's book of the same name is a product worth ~$30, I assumed there was a paywall at some point behind https://www.hackerrank.com/domains/tutorials/cracking-the-co... -- I guess I was wrong? It doesn't clearly say on the page that it was, and I don't want to sign up for their product.

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.

They make money by selling the snake oil that are these tests and interviews. They need interviewers to believe they are useful and diagnostic, and they need interviewees to put up with them and think it's acceptable to be put through it.

Had a look myself. There isn't.

Exactly. What kind of hiring "bar" is it if all it measures is the motivation (or more specifically: degree of desperation) necessary to pony up for a 30-day cram school... led, not coincidentally, by the very company that's administering your weeder tests?

> led ... by the very company that's administering your weeder tests?

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.

The College Boardification of software has begun. Arguably it was already here back when companies were hiring based on candidate SAT schools and college pedigrees, this is just a new chapter with sw interviewing platform firms becoming the new Princeton Reviews.

Along with the "Top 20 Startups to Work For in 2017" mentality.

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?

then do it like I do. Whenever they send you a link to one, don't take it. Explain you are more than happy to talk to an engineer but you won't do some random online test.

(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 have begun doing this. The RoI just isn't there for me.

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.

Yeah, you have to pretty much assume that if you balk on their "weeder" test, they'll balk on you.

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.

I was polite but ended a phone interview recently when they wanted me to code in a Google Document.

Good call. The sheer idiocy of expecting people to show off their mad hacking skills in such an obviously crippled environment is just... breathtaking. Especially when the cost of renting a session on one of the services that does offer a full-featured IDE (with vi and emacs modes) is close to zero.

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.

This is really misguided. As a programmer you should be able to write a few lines of code in a Google Document.

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).

I've written code for pay for over two decades in a variety of languages and on a variety of platforms. I can say if I don't wish to write code into a Google Document, nothing misguided about that. Someone fresh out of school, maybe, even then, most coders are using an IDE all day or have another window or terminal open so we can do a quick compile sanity check so even for a new coder fresh out of school, this makes no sense.

You should be able to write code with half-busted crayons on the back of yesterday's newspaper, also. But it's much classier (and time-efficient) for all concerned if the employer provides at least ballpark-adequate tools upfront (meaning at the very least an editor that doesn't overtly work against you -- like Google Docs does).

Imagine a world where the interviewers sat a candidate down in the company's typical environment, with a simplified version of their codebase, and asked them to re-implement a small piece of striped-out functionality. Give them a couple of hours, and then allow them to ask questions, explain what they did, where they got stuck, and give their own feedback. Now you know that they understand your environment/stack, and get an actual sense of how they would perform for your company on code that matters. Let them see the actual code you use at the end, and discuss differences, why they made certain choices, and see if they get excited or frustrated with your company's practices (style, systems, conventions).

Yeah, some companies do those (or a slight variation, called pair programming interviews). There are a lot of benefits of those, but also some drawbacks.

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.

> 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.

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 didn't say it did.

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 can be gamed by reading a book sold by the process giver is especially flawed and morally corrupt.

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.

> A hiring process that can be gamed by reading a book sold by the process giver is especially flawed and morally corrupt.

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.

I have no idea why I am being compared to Donald Trump.

> 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.

People don't consider that not only does the software engineering process weed out those that don't know algorithms, it also weeds out those that don't have the discipline to sit down and study for a couple of weeks.

I did not create this process.

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.

Essentially younger are better amiright? Otherwise why are they smarter than someone who actually has real world experience? Is your new grad smarter than Jeff Dean? Or Rob Pike?

Nope. Not even close to what I was saying. In fact, I repeatedly said that I am NOT saying that inexperience people are better/smarter. I'm not sure how you got to that, other than pure determination to believe I was saying that.

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.

Experience tells me you are wrong. Experience will also tell the young ones why they are wrong.

Wrong about what? That all hiring processes are flawed? That some new grads could be better than some experienced hires, 6 months down the road? That build-a-project-in-3-hours doesn't weight experience heavily?

How does repeating the same tasks every day for 20 years make someone a better software engineer?

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."

I agree in principal - I was being slightly facetious (as I hope you were with the 6 month figure).

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.