Hacker News Reader

Comment by krschultz | Hacker News Reader

> Second—people who had spent the last month memorizing the “Cracking The Coding Interview.” They will pass as well, but you will have no assessment of whether they can apply their knowledge. That is, until their first deployment to your production environment.

Everyone criticizes this, including me before I decided to capitulate to the system and do it myself. But it's actually kind of fair? Everyone knows the game. Some people will choose to train hard enough to play, some people will not. That is a signal in of itself as to whether the candidate will work well in the big tech company environment.

View on HN

I didn't read it as criticism of the engineers reading “Cracking The Coding Interview.” - if you want to pass algorithmic interviews you have to read it or something equivalent - or be fresh out of college.

But just as this post says, as a hiring manager, you'll get very little insight into how good the candidate is until after you've hired them. This does serve as a weak signal for dedication, but:

1. You don't want to make your hiring decision only based on dedication.

2. There are other, better signals for dedication.

>>very little insight into how good the candidate is until after you've hired them.

The fact that one depends on a proxy measurement which has little correlation with actual results is the core of the problem here.

Hey! To be fair, we don't criticize it (blog post author here), nor do we discourage such training, of course. It is perfectly valid and could be a good ROI, as you mentioned. What we found out is that using algorithmic knowledge as a metric for hiring was suboptimal. As other people mentioned, there's plenty of people w/o formal CS background who can deliver, and there's plenty of people who know algorithms by heart but have trouble shipping things. There's some correlation, of course, but I would say those are different dimensions.

And then it looks like this: when hiring someone, the company measures them by one dimension and then expects them to perform on another one. I did get some backlash for comparing engineers to cooks, heh, but the main point is and always was about choosing the right metric.

You are just testing willingness to jump through hoops in order to get the job (and, hopefully, to keep it). Which could be all that is needed for a megacorp job. In a workplace where you are very likely have more than enough brainpower to solve any problem just because of its size, teamwork and loyalty are much more important than expertise.

In a smaller company this is not true though. If you only have 10 engineers there is a good chance that none of them is qualified enough to solve the current problem so even if they all are extremely loyal and cooperative - the problem will remain unsolved. Even with a 100 you might end with just ~10 experts who are going to be overextended, burn out and quit. So, while loyalty and teamwork are still important, you really, really want to test for the actual expertise in a small-medium company. Unless you don't foresee any hard problems, then hiring for loyalty is the best you can do.

In a workplace where you are very likely have more than enough brainpower to solve any problem just because of its size

Except that a company that's 10 times as big is working on 10 times as many things. The idea that a huge company can afford to hire just anyone because they're so huge and they only need a few smart people is ludicrous. If that were the case, these companies wouldn't feel the need to pay so much.

It does not matter as long as 99.9% of those things are a mix of busywork and trivial problems.

The scenario I have in mind is something like this: you make an app, your team manages UI, backend, whatever, just fine - it's simple and is 99% of the job. You release your app and a million people download it, next day you are flooded with crash reports, it crashes for 25% of the users!

Megacorp: calls a special team of greybeards who spend 24 hours digging and find it's a bug in a driver for some popular chipset. They write a fix in another hour, file a bug with the popular chipset manufacturer and return back to playing WoW.

Small business: panic, panic some more, post questions on stackoverflow, really panic, find a bogus solution, release a patch in a week which makes the app crash even more because it's rushed and is actually breaking things by design, go back to panicking. The app gets bad rep, even people who had no problems are dropping it, its reputation is destroyed. The small business tries to pivot and shuts down in 6 months.

Problems like this do not happen often but when they happen it may end the business so you don't need a lot of resources to solve them but if you have 0 then you are not going to last.

Except the problem didn't happen after the bug was revealed. The problem happened before, during development. Better engineering, better development practices, better engineers, is what you need to avoid problems like that.

And you don't get better engineers by hiring just anyone who comes along.

Yes, better engineers would have caught it before release, maybe. This is why I am saying that testing for loyalty makes no sense for smaller companies as a loyal engineer may not be any good. I can even speculate that the best engineers are unlikely to be very loyal e.g. I doubt Google makes its "stars" to jump through the hoops.

Don't you think that requiring candidates to spend a month studying makes it so that only candidates that can afford to do so are hired? Some people have other responsibilities outside of work that mean they simply cannot spend time memorizing a book. It adds insult to injury that for the vast majority of the time, you won't use anything from that book. And the interview doesn't test for skills that you actually do use at your job.

The best whiteboard/leetcode engineer I was involved in hiring and worked with was absolutely terrible at designing and coding real software. The signal of dedication is a pretty poor proxy for real capability.

Just wondering, was it any good? Would you say it played a big part in passing whiteboard coding and landed your current job? Asking because I'm thinking of doing it myself..

Absolutely. I went to the local library every Saturday for a month or two and did practice problems without distractions. Total prep time was probably ~40 hours.

My compensation increased by at least $150,000 a year.

Best ROI I've gotten on anything I've done in my life.

I tell that stories to people considering doing it all the time, you'd be amazed how many people hear my experience and say, yeah, naw I'm not going to spend that time.

¯\_(ツ)_/¯

Totally agree. I spent a lot longer (months!) on a very challenging real-world side-project, hoping that would be the ticket to a job.

At the end of the day, it was the ~40-60 hours I put into Cracking the Code Interview that got me the FAANG job, the side project was barely a blip.

40 hours worth of work is a lot.

That's a weeks wage on what is essentially a lottery ticket, albeit with good odds. (Having done some freelance work for a friend in my Spare time, finding 40 hours free is going to take me weeks).

Meanwhile, I’ve put hundreds of hours of prep in and never received an offer from FAANG.

It really is a lottery ticket. Luck plays a ridiculously large part of the interview.

I had a phone / screenshare interview with Google one day. Asked me to solve a Soduko problem (I have never done a Sudoko until that point). Didn't get it.

Half an hour later wandering done the street a very elegant solution came to me. I wouldn't say I am bad algorithmic stuff, but as I never practice it's pretty random whether I will get during an interview. "Luck" as you say.

How many problems did you practice?

What was your question bank.

I did all the medium & hard ones in there and was getting through them pretty consistently. I also don't have a CS degree so prior to that book I took the online Stanford algorithms class, I'm not including that in the 40 hours of work because I think most people reading this probably have more formal education in the field than I have.

Reply on news.ycombinator.com