Hacker News Reader

Comment by kafkaesq | Hacker News Reader

Engineers have used Coderust to crack the coding interviews at Google, Amazon, Snapchat, Uber, Dropbox, Lyft, Facebook, Microsoft, Netflix, Zenefits, Pinterest, eBay, Twitter, Cloudera, Salesforce, Tableau and many others.

If one can "crack" these interviews by spending a couple of hours on some interactive tool... then shouldn't that be an indication to those conducting these kinds of interviews that, fundamentally speaking, they might not be all that useful in the first place?

And not only that - but perhaps counterproductive? In that they explicitly reward not the thoughtful, disciplined engineers you want to hire -- but the drudges and go-getters who think, "Gots to get me into a top company - just tell me what I gotta do to pass the test!"

Shouldn't it now?

View on HN

Kindly consider, please, the predicament of the extremely experienced engineer who has been obliged to present a solid hire/no-hire opinion after conducting a technical interview.

Do you really think that we're going to just look for correctly memorized answers to rote shibboleth questions and then tell the hiring committee "sure, $CANDIDATE would be a great programmer!" ??

The quote is a fancy marketing line to sell a product. Good companies don't use a coding test to straight out determine hirability. Or at least they shouldn't.

95% do.

They aren't 100% determinative, of course. But by and large, many companies do place a great deal of emphasis on ones performance on these tests (perhaps being only partly conscious of the extent to which they're doing so).

Yes but no one actually gathers the proper metrics. Moreover, no one is large enough to gather meaningful metrics. Finally, for those that are and potentially do, they still seem to gravitate to "implement this algorithm which we could get a trained monkey to learn by memorizing" only "cleverly" encoded in a "question."

Btw, engineers love algorithm & data structures questions because they're easy to judge and learn. Not because they're good at judging candidates.

Thankfully, people don't "crack" Amazon interviews for SDE/SE roles with Coderust or simply memorizing mergesort.

Interviews have more to do with signaling than actual ability to do the job, in all the dimensions that are necessary.

Doing well on CS puzzles is and probably still be required for a long time to come. More of a hazing ritual. What I think should be allowed is for the interviewee to pose the same kind of ridiculous question to the interviewer, if the interviewer fails, the candidate takes their job.

This doesn't align with my experience. I just interviewed with Amazon a few days ago, just testing the waters to see what's going on in the rest of the world, and it was very 'leetcode'-ish. So much so that I ended up just telling the recruiter I wasn't interested in the position anymore. One question more or less required me to code up a BST from scratch and traverse it. I felt like I was back in my undergraduate algorithms class.

If I ever really needed another job, I guess I'd have to suck it up and refresh myself on that stuff. That's a shame.

Exactly. That's the name of the game today: You need to spend a week refreshing your algorithms and data structures and you can certainly "crack" those interviews.

I never got the point of it, but I see it as a ritual...

The grass is always greener. I switched to software dev from academia. There, instead of whiteboard tests, it was all about networking, letters of recommendation, having the right advisor, etc. I'll take the whiteboard any day!

Good point. Someone was making an argument the other day that a whiteboard algorithm interview is still relevant as it proves that you are able to sit down and learn your algorithms again. (Basically it proves that you are able to learn when needed).

Is coding a BST and traversing it that big a deal?

I routinely code tree traversals at my work, so my judgement may be clouded here, so I am genuinely curious here to know if most people here think that it is unreasonable to expect someone to code a BST from scratch.

In my opinion, BSTs are one of the easier things in programming, with a complexity that is maybe only a little above a for-loop. Most often, in real world, the more complex stuff happens in the business logic, or API contracts, or that sort of thing outside tree traversals.

Yes, I think you're lucky to be in a somewhat unusual position that let's you regularly work with problems like that.

I'm merely a junior level developer working on database engines. Most of my day-to-day involves maintenance of decades old code where the 'hard problems' have long been solved. I imagine my codebase ancestors might have needed thorough knowledge of trees at some point :)

Reply on news.ycombinator.com