Live data from Hacker News

Algorithms Interviews: Theory vs. Practice

danluu.com

11–20 of 77 posts

Re: Algorithms Interviews: Theory vs. Practice

#11
I actually suspect that one of the main purposes of the algo based interview process is a motivation check. It takes time to prep for these interviews. Lots of time. So if you get a candidate that is crushing problems, it can either mean two things:

1) They are exceedingly brilliant and they can program decently

2) They have studied hard, they can reason and code decently

Combine that with a system design portion and some behavioral questions, and the company is probably getting a solid hire. Does it mean that you're weeding out some false negatives? Absolutely. But large companies don't care. The system works well enough, and until it doesn't, I doubt much will change.

Re: Algorithms Interviews: Theory vs. Practice

#12

>"I’ve done maybe 40-ish "real" software interviews and passed maybe one or two of them" I'd say that about mirrors my experience as well. Is this really that common? Here I was thinking that I'm just an idiot.

According to Dan, you're both outliers: https://twitter.com/danluu/status/1058029337923014656 .

>"I'd never thought about it this way before (look at who gets rejected and see what they have in common), but I guess there's one thing interviews are pretty good at filtering for: people who are a certain type of nervous in interviews."

Sounds about right. I can pass "take home quiz" style interviews at nearly 100%, but put me in front of a whiteboard and everything goes blank. Not sure why people insist on doing that.

Re: Algorithms Interviews: Theory vs. Practice

#13
post #3

> At one point, after getting a promotion and a raise, I computed the ratio of the amount of money my changes made the company vs. my raise and found that my raise was 0.03% of the money that I made the company, only counting easily quantifiable and totally indisuptable impact to the bottom line. Would profit/revenue sharing help with this?

Except supply and demand drive your pay, not how much you make the company. Now, if you can't make the company at least as much as you cost, then you're out of a job.

Those "I made the company X" arguments are only interesting if it was an action/idea that you were uniquely responsible for. If it's something most equally qualified people would have done in that role, it's not that interesting.

Re: Algorithms Interviews: Theory vs. Practice

#14

> Some companies will give very large out of band bonuses to people, but that work wasn't for a company that does a lot of that kind of thing, so there's nothing the company could do to indicate that it valued additional work once someone did "enough" work to get the best possible rating on a performance review. From a mechanism design point of view, the company was basically asking employees to stop working once the…

> to try to get people to leave the team and join less effective teams

From a director-level perspective it probably makes sense to have one or two of your best people on each team, rather than some wholly excellent teams and some wholly mediocre teams.

Re: Algorithms Interviews: Theory vs. Practice

#15
> The most widely read programming blogger around (Joel Spolsky) was telling people they need to adopt software practice X because Microsoft was doing it and they couldn't compete adopting the same practices.

These days, it's amazing how much "We do X because Google does X" you see. But Google is the new circa 2003 M$, so it makes sense.

Re: Algorithms Interviews: Theory vs. Practice

#16
post #3

> At one point, after getting a promotion and a raise, I computed the ratio of the amount of money my changes made the company vs. my raise and found that my raise was 0.03% of the money that I made the company, only counting easily quantifiable and totally indisuptable impact to the bottom line. Would profit/revenue sharing help with this?

Except supply and demand drive your pay, not how much you make the company. Now, if you can't make the company at least as much as you cost, then you're out of a job. Those "I made the company X" arguments are only interesting if it was an action/idea that you were uniquely responsible for. If it's something most equally qualified people would have done in that role, it's not that interesting.

Not true. Making the company X amount or your out is thinking to linear. There are profit centres and profit eater departments. Keeping your job is more political than values based.

Re: Algorithms Interviews: Theory vs. Practice

#17
post #3

> At one point, after getting a promotion and a raise, I computed the ratio of the amount of money my changes made the company vs. my raise and found that my raise was 0.03% of the money that I made the company, only counting easily quantifiable and totally indisuptable impact to the bottom line. Would profit/revenue sharing help with this?

Except supply and demand drive your pay, not how much you make the company. Now, if you can't make the company at least as much as you cost, then you're out of a job. Those "I made the company X" arguments are only interesting if it was an action/idea that you were uniquely responsible for. If it's something most equally qualified people would have done in that role, it's not that interesting.

Even if you were uniquely responsible and it’s something extremely difficult hat few could accomplish, there is no way to prove it and the company usually treats you just like any other idiot hired at your “level”.

Re: Algorithms Interviews: Theory vs. Practice

#18

> Some companies will give very large out of band bonuses to people, but that work wasn't for a company that does a lot of that kind of thing, so there's nothing the company could do to indicate that it valued additional work once someone did "enough" work to get the best possible rating on a performance review. From a mechanism design point of view, the company was basically asking employees to stop working once the…

> to try to get people to leave the team and join less effective teams From a director-level perspective it probably makes sense to have one or two of your best people on each team, rather than some wholly excellent teams and some wholly mediocre teams.

From the standpoint of providing skill-mentorship opportunities it makes sense. A few strong engineers on a team can really help everyone grow. Naturally personalities and preferences should be accounted for, however one of the best moves I ever made was to break up a "ninja squad" (what they called themselves) of high functioning devs when their big project wrapped up. The squad was small (3) and each person was very well liked by the entire engineering team (13). We had several green-field projects starting up, so none of them felt banished to the salt mines of legacy maintenance tasks for instance. The general quality and velocity improved across the teams and we gained more consistency in our codebase when it came to patterns.

Re: Algorithms Interviews: Theory vs. Practice

#19
Opening statement:

> When I ask people at trendy big tech companies why algorithms quizzes are mandatory, the most common answer I get is something like "we have so much scale, we can't afford to have someone accidentally write an O(n^2) algorithm and bring the site down"

In 20yeara I've never heard someone say anything like that.

Re: Algorithms Interviews: Theory vs. Practice

#20

>"I’ve done maybe 40-ish "real" software interviews and passed maybe one or two of them" I'd say that about mirrors my experience as well. Is this really that common? Here I was thinking that I'm just an idiot.

I feel that way about applying. 40 resumes maybe two calls.
Post reply on HN