Live data from Hacker News

Algorithms Interviews: Theory vs. Practice

danluu.com

51–60 of 77 posts

Re: Algorithms Interviews: Theory vs. Practice

#51

Its hard to believe that Dan Luu can’t pass algorithm interviews.

It has a lot to do with psyche. If you have anxiety, it is entirely possible to even fail the most basic questions. And unfortunately, you can't just say "Sorry, I'm having a panic attack. Could we do this tomorrow?".

I think the best course is anxiety management. But unfortunately, some people get dependent on drugs just to calm their nerves before something important. I know people that can't hold meetings or presentations without taking beta-blockers and the likes.

Re: Algorithms Interviews: Theory vs. Practice

#52

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

> Accepting that organizations are incentivized to extract the maximum amount of value from you

Perhaps that is true at start ups, but in my career as a developer at very large corporations this has been almost never true. Most of my career has been waiting around wasting time or working on side projects to do my job for me. That time waste is due to any of the following:

* Unnecessary build jobs, such as a build job that takes 90 minutes. In that extreme example Java was the center-piece technology at a web travel company even though Java is not a web technology. As a front-end developer if I wanted to make a code change and test it in the browser I would need to rebuild and wait 90 minutes, because the front-end code that the Java developers don't care about is at the end of the funnel. No incentive to hurry and certainly no maximum value extraction.

* When I was working as a strategy consultant to a different giant web travel company I was there because they sucked. Let's be honest, if they were awesome they wouldn't be spending huge bags of money on an outside consultant for advise. Because the most sucky developers there were supremely insecure and their management was at war with another department they didn't really want me to do work. I really tried to justify the money they were paying to my employer for my time there, but it was really just an exhaustive exercise in keeping busy so I wouldn't be bored all day. Eventually that faded away and I just started taking long walks out of the office. No value extraction there either.

* A more common scenario I have experienced is death by process. Its like bleeding out from a thousand tiny paper cuts such that you are in agony forever, but there is no light at the end of the tunnel. I have reasoned this madness occurs because the organization lacks a qualified architect and the wrong personalities were put in charge of the technology decisions. In nearly all cases management looked around and said to themselves "who here mindlessly works themselves to death" and then that person gets put in charge and now everybody is working themselves to death but nothing is being produced. Nothing says working hard like running as fast as you can on a mouse wheel. In these cases there is need to be constantly in a hurry, but nothing gets done and everybody knows it and morale is destroyed.

* The most common failure I encounter is fear of writing original code. As a front-end developer there are only 2 APIs on the front-end: DOM and the Web APIs. Instead of writing a fast performing solution in the fewest possible instructions you typically need to write the code to conform to a very specific, though not documented, code style on top of a giant monster framework with a 1000 dependencies. Then you need to compile the code more than once just for good measure. Even though the problem could be solved slowly in 30 minutes with an additional hour for testing in multiple applications/environments it will likely take a week or more in the framework. Sometimes people claim there is a great hurry to ship product changes, but as a developer working on a framework made out of toothpicks and duct tape the hurry is clearly somebody's self-serving imagination.

* I think everybody's favorite value destroyer is death by JIRA. So, JIRA is an Agile planning and assignment tool that the corporate world has fallen in love with. When everything is a story point and nothing else matters your personal goal becomes completing story point assignments and then doing nothing else.

Perhaps the only times I have ever experienced a big corporate employer making any attempt to extract the maximum amount of value from me is when work used the old waterfall methodology, because the work was constantly coming in without regard for schedule cycles or administrative nonsense. The time I was most most valued is when I was told to go as fast as possible as the A/B test engineer for Travelocity and all restrictions were on productivity, aside from Q/A and defect resolution, were eliminated.

---

> 1. Aware of the value you produce 2. Know how to sell it

I, and most people I have worked with, have spent so much time undervalued that we clearly had time to really and continuously sell ourselves like a product on a shelf, but nobody almost wants to. The people that spend the most energy selling themselves instead of writing code or solving problems tend to use charisma as for bad self-promotion. If developers wanted to spend the majority of their energy in marketing they wouldn't waste time solving hard technology problems. It reminds me of end of year evaluations that most developers dread.

Re: Algorithms Interviews: Theory vs. Practice

#53
post #43

Earlier quoted context omitted.

I think most interviews are designed to find people similar to the interviewers, whether they realise it or not. If you think it works "well enough", I think you're just fooling yourself. I say that as someone who has gotten a job offer from every interview I've been interviewed, and done maybe 100 on the interviewer side of the table. I put far more weight onto pair programming and anything that resembles a work sam…

Getting an offer from every interview is impressive, good for you (you don't cite how many but I'm assuming you've done a good number in different contexts). Even the smartest people I've known have had mixed luck with interviews, due to some combination of randomness, poor interview design, or just poor fit for that company. As for administrating 100 interviews, you'd prob rack those up in a 2 year stint at a FAANG…

I'm 40 (ouch!) and I've done about 6 serious interviews - other conversations over lunch and whatnot, that I didn't pursue - I'm not a serial interviewer, granted. Three job offers I declined.

Where I work today, I'm in the last round of interviews, to try and reduce the time consumption.

My real point is that a work sample is really hard to get in an interview, and it's really not fair to fire someone in their evaluation period because they're only average, and not extraordinary, with what they come up with in day to day work.

Re: Algorithms Interviews: Theory vs. Practice

#54
post #16

Earlier quoted context omitted.

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.

The idea of a "profit eater" department makes no sense to me. Sure, your IT department or janitorial staff or whatever aren't being directly handed money by clients, but your business would not be able to run without them. Surely they're only a negative profit center by a very myopic, naive definition of the term?

Re: Algorithms Interviews: Theory vs. Practice

#55
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?

No. Profit sharing gives you money based on the overall profitability of the company. However, even if your contribution is enormous, it's unlikely to make more than a barely perceptible change to the overall profitability of the company, meaning the impact on your own pay will be tiny. Profit sharing works by trying to make employees feel connected to the success of the business, but they don't make sense based on a…

"even if your contribution is enormous, it's unlikely to make more than a barely perceptible change to the overall profitability of the company"

Too bad this rationale isn't routinely applied to senior managements/officers, eh?

Re: Algorithms Interviews: Theory vs. Practice

#56
So, amusingly, my referral hit rate at Google is like 1/10. Worse, I only refer people if they've told me that they're certain they wish to go through the terrible process.

When I say 1/10, I don't mean 10%, I mean I have entered about 10, and only one got an offer. In my opinion, all were qualified and should have been given offers. For comparison, I've done roughly 100 interviews or something (though not nearly enough SWE interviews, because I'm in San Francisco). As an additional upwards bias, I actively discourage people from applying, so this is only the folks that said "I understand, refer me anyway".

All that said, Google is really more like dozens of independent companies now. There's Search/Ads, YouTube, Cloud, Photos, Android, Maps/"Geo", and so on. Your mileage will vary pretty drastically depending on how you're routed. Just like Dan was misdirected towards a software interview, I've had friends tossed into the SRE hiring pipeline, asked how to operate large-scale distributed systems and so on, when their background is "Umm, I just did my PhD in CS in Graphics... I've never written a networked program in my life".

To all the other Google employees: find the job posting internally that your friends would actually want, talk to the hiring manager to figure out what that maps to externally on the job postings page (it often doesn't), and then tell the assigned recruiter that you're serious about your recommendation. The recruiter may still override you in deference to their hiring targets / goals though (the one offer I've seen from my referral went this way despite my effort), so don't promise your friends that you can fix it for them.

I'm not here to excuse these hiring practices. Instead, be honest with yourself about why you want to apply, and how much hassle you're willing to put up with. In my experience, all other companies will decide more quickly on your hiring result, role, level, compensation and so on. I believe that's because of the scale of the interviewing and hiring (>10k full-time employees per year for the last few years), except it's always been pretty bad at Google.

Re: Algorithms Interviews: Theory vs. Practice

#57

Earlier quoted context omitted.

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

I wouldn't call 25% an outlier. Also, that's only people he knows. The numbers from interviewing.io (Aline Lerner) suggest that interview performance is arbitrary[0] and that engineers are bad at gauging their own interview performance[1]. The numbers suggest it's far more common than just 25%. [0]: http://blog.interviewing.io/after-a-lot-more-data-technical-... [1]: http://blog.alinelerner.com/people-cant-gauge-thei…

> I'm one of four people I know of who fails interviews at a high enough rate that I could fail 20 in a row (and I believe I have).

My reading of that is that out of all the people he knows, there are four that could plausibly "fail" 20 interviews in a row, not that 25% of (engineers?) he knows would do so.

Re: Algorithms Interviews: Theory vs. Practice

#58

Earlier quoted context omitted.

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

if you have such unique and powerful skill that you can attribute to this level of value production, then your only option is to found a startup and extract 100% of that value from said skill.

Re: Algorithms Interviews: Theory vs. Practice

#59
post #16

Earlier quoted context omitted.

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.

The idea of a "profit eater" department makes no sense to me. Sure, your IT department or janitorial staff or whatever aren't being directly handed money by clients, but your business would not be able to run without them. Surely they're only a negative profit center by a very myopic, naive definition of the term?

> your business would not be able to run without them.

but can your business earn more if had more of them? If yes, then it's a profit center. If no, it's a "profit eater".

Re: Algorithms Interviews: Theory vs. Practice

#60
post #59

Earlier quoted context omitted.

The idea of a "profit eater" department makes no sense to me. Sure, your IT department or janitorial staff or whatever aren't being directly handed money by clients, but your business would not be able to run without them. Surely they're only a negative profit center by a very myopic, naive definition of the term?

> your business would not be able to run without them. but can your business earn more if had more of them? If yes, then it's a profit center. If no, it's a "profit eater".

> but can your business earn more if had more of them?

But that's true of everything. If you hire 100% more salespeople (generally considered a "profit center") but don't also hire a proportionate number of extra devs and IT and janitors you're not going to make more money either.

Simplifying a bit, but there's "right amounts" of all types of employees - if you don't have "enough" devs/salespeople/support staff/IT/janitors, then hiring more will result in you making more money.

Post reply on HN