Live data from Hacker News

Data structures and algorithms I actually used while working at tech companies

blog.pragmaticengineer.com

391–400 of 547 posts

Re: Data structures and algorithms I actually used while working at tech companies

#391
post #329

Earlier quoted context omitted.

This absolutely! The interview process is totally broken, as it tests mainly how much someone is willing to prepare for the interview, which might actually show more how little they focus on doing more productive things in their current job, at university or by starting interesting projects. It also scares away people who might actually be better at the job but not as good or interested in interviews - at least this…

I still do algorithms interviews, sort of. The one-hour interview format is an external constraint, so within that constraint I will do ~40 minutes of coding and ~15 minutes of discussing past projects. I ask a question where the algorithm itself is at most some list iterations or tree traversals, but the real difficulty is thinking through the data and figuring out the right generalizations and transformations to ap…

This all makes sense, thanks for the details.

I think the key element is how you calibrate towards the candidate, bringing common sense into the process. This is something Google tried to cancel out to increase fairness, which failed in my experience.

Maybe another issue is setting the bar too high during the interview to improve the metric on retention, sometimes it might just not be the match that the interview appeared to have.

I usually try to work with people on something small to get a feeling for how well we work together before committing to larger projects, but at some point I’ll need to start hiring, so I’m very interested in this topic.

Re: Data structures and algorithms I actually used while working at tech companies

#392
post #341

Earlier quoted context omitted.

My favorite question to ask in software engineering interviews is one that I believe to be un-burnable. > It's 2140 AD, New York is under water up to X feet high. Buildings have been retrofitted with to withstand the water. You are in charge of keeping your building dry. If water gets in and damages the foundation, a few thousand people die or become homeless. > Design a system that ensures that doesn't happen. How c…

Me: "I'm a software developer, so I would let a material science engineer figure it out." You: "You can't do that... All the material science engineers have drowned." Me: "That's not very realistic..." You: "Thank you for your time. Don't call us, we'll call you."

"Ok the material science engineer gave you the fancy material. It was applied. As you know, nothing is perfect and lasts forever. How do you ensure your building doesn't sink?"

Re: Data structures and algorithms I actually used while working at tech companies

#393
post #351

Earlier quoted context omitted.

That may be true. But then why hire someone with just look-up skills before hiring someone who really tries, and enjoys the challenge? I'm interviewing engineers frequently and although I agree that the question asked by GP is maybe not the best it still gives the signal if someone is willing to power through a problem with minimal guidance and/or ambiguous constraints. Something I'm willing to find out at the peril…

> why hire someone with just look-up skills before hiring someone who really tries, and enjoys the challenge This attitude will keep you from hiring someone who will just "do the right thing," which is to look up stuff that can be looked up, and also persevere when an off-the-shelf solution won't be sufficient. Plenty of engineers will spend time trying to reinvent the wheel when it is totally unncesssary.

True, but in my experience it's easier to teach resourcefulness after hiring than injecting motivation for solving problems somehow.

Re: Data structures and algorithms I actually used while working at tech companies

#394
post #341
post #336

Earlier quoted context omitted.

Yea I interview (and have sat on HC) at Google, and interviewers who ask these types of questions really frustrate me. If your question requires having previously memorized or being able to come up with some tricky algorithm on the fly in 45 minutes and code a solution using it , your question is probably bad. I get why they ask them - they're easy to ask, they're easy to score, and when your question inevitably gets…

My favorite question to ask in software engineering interviews is one that I believe to be un-burnable. > It's 2140 AD, New York is under water up to X feet high. Buildings have been retrofitted with to withstand the water. You are in charge of keeping your building dry. If water gets in and damages the foundation, a few thousand people die or become homeless. > Design a system that ensures that doesn't happen. How c…

Use to build a wall around the city? Have the people who maintained each individual building form a team that can keep an eye on sections in shifts? If we have enough magic material, build a double wall system for breaches?

I'm done. Give me my paycheck.

Re: Data structures and algorithms I actually used while working at tech companies

#395
post #304

This article is hurting its credibility right from the get-go by un-critically reproducing yet again this tired saw from Max Howell: > Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off. First, it's not remotely true that 90% of Google engineers use Homebrew, seeing as how almost all development is done on Linux (Max Howell is unjustifiab…

Most Googler SWEs have Mac laptops, not linux or windows laptops. But only a fraction of them use brew to install additional software. I'd love to interview the creator of homebrew. There are so many dependency and reliabiltiy questions that it's clear brew doesn't handle well (same criticism of CPAN, and pip to some degree) in terms of performance or correctness that you could just talk for an hour about graph probl…

Googlers tend to use their Mac laptops as glorified remote desktop terminals, because they aren't allowed to so much as check out code to portable computers that can leave the office.

It's a running joke that $2k top-of-the-line Apple laptops are being used as remote desktop terminals when much cheaper hardware would be perfectly sufficient.

Re: Data structures and algorithms I actually used while working at tech companies

#396

Earlier quoted context omitted.

IQ is a measure of mental flexibility independent of context. Being able to solve tricky algorithm problems is a measure of mental flexibility in the context of programming. The two are strongly correlated. Of course, the test is confounded by a baseline of programming and CS knowledge.

This is absolutely not true. I have seen amazing scientists and engineers get turned down by FAANG companies because they did not happen to study particular algorithms that were featured in that day's set of questions, and mediocre engineers fly through because they put in more time studying, or perhaps got lucky with the subset of technical questions that were asked.

Yes, such tests are subject to a certain amount of gaming and prior knowledge. But that doesn't invalidate the fact that they are correlated with raw intelligence.

Re: Data structures and algorithms I actually used while working at tech companies

#397

Early in my career, I interviewed at Google. One of the interviewer asked me to recite the algorithm for constructing a Convex Hull. Since I hadn't done anything related to convex hulls since my algorithms class as a sophomore in college (several years earlier), I couldn't remember all the details. At some point, I said, I know where in CLRS ( https://www.amazon.com/Introduction-Algorithms-3rd-MIT-Press... ) this is.…

I had a very similar experience interviewing for Google. I was asked to do a task that eventually boiled down to a topological sort, and I thought the question consisted of recognizing that the answer was a topological sort and moving on because it was over the phone. However, that was not the case. The interviewer wanted me to code it all out over Google Docs, but I didn't remember the exact algorithm so I basically…

A passage from one of Jon Bentley's Programming Pearls:

As soon as we settled on the problem to be solved, I ran to my nearest copy of Knuth's _Seminumerical Algorithms_ (having copies of Knuth's three volumes both at home and at work has been well worth the investment). Because I had studied the book carefully a decade earlier, I vaguely recalled that it contained several algorithms for problems like this. After spending a few minutes considering several possible designs that we'll study shortly, I realized that Algorithm S in Knuth's Section 3.4.2 was the ideal solution to my problem.

If Bentley needed to go look up an algorithm that he vaguely recalled studying in the past, just how awful of programmers are the rest of us that look things up, really?

Re: Data structures and algorithms I actually used while working at tech companies

#398
post #341
post #336

Earlier quoted context omitted.

Yea I interview (and have sat on HC) at Google, and interviewers who ask these types of questions really frustrate me. If your question requires having previously memorized or being able to come up with some tricky algorithm on the fly in 45 minutes and code a solution using it , your question is probably bad. I get why they ask them - they're easy to ask, they're easy to score, and when your question inevitably gets…

My favorite question to ask in software engineering interviews is one that I believe to be un-burnable. > It's 2140 AD, New York is under water up to X feet high. Buildings have been retrofitted with to withstand the water. You are in charge of keeping your building dry. If water gets in and damages the foundation, a few thousand people die or become homeless. > Design a system that ensures that doesn't happen. How c…

Seems reminiscent of the tales of early 2000s Google interviews, of the "estimate how many golf balls fit in an airplane" variety.

I'm not convinced this offers a useful selection criteria other than boosting your unconscious bias on who "seems smart", but on the other hand I'm also not convinced it's any worse than the standard modern Leetcode interview.

Re: Data structures and algorithms I actually used while working at tech companies

#399
post #304

Earlier quoted context omitted.

Most Googler SWEs have Mac laptops, not linux or windows laptops. But only a fraction of them use brew to install additional software. I'd love to interview the creator of homebrew. There are so many dependency and reliabiltiy questions that it's clear brew doesn't handle well (same criticism of CPAN, and pip to some degree) in terms of performance or correctness that you could just talk for an hour about graph probl…

Googlers tend to use their Mac laptops as glorified remote desktop terminals, because they aren't allowed to so much as check out code to portable computers that can leave the office. It's a running joke that $2k top-of-the-line Apple laptops are being used as remote desktop terminals when much cheaper hardware would be perfectly sufficient.

I replaced my MacBook Pro with a Google Pixelbook since indeed my work is all remote and I don't really like MacBooks. I've previously tried high end Dell laptop (the most amazing laptop I've ever used, it had a high end nvidia GPU and you could train models on an airplane) and ended up with this device.

I wish it was slightly larger with better specs and more ports, only because I spend a lot of time in video chat and there isn't enough CPU oomph to do video chat and Google docs on an external display.

Re: Data structures and algorithms I actually used while working at tech companies

#400

Early in my career, I interviewed at Google. One of the interviewer asked me to recite the algorithm for constructing a Convex Hull. Since I hadn't done anything related to convex hulls since my algorithms class as a sophomore in college (several years earlier), I couldn't remember all the details. At some point, I said, I know where in CLRS ( https://www.amazon.com/Introduction-Algorithms-3rd-MIT-Press... ) this is.…

I had a very similar experience interviewing for Google. I was asked to do a task that eventually boiled down to a topological sort, and I thought the question consisted of recognizing that the answer was a topological sort and moving on because it was over the phone. However, that was not the case. The interviewer wanted me to code it all out over Google Docs, but I didn't remember the exact algorithm so I basically…

Man, one time I had an interview at a startup. They asked me some fairly trivial questions and I wrote some pseudocode which they were fine with. Then in the last 5 minutes they were like, "well, let's get this ready to run in a browser." I was shocked and stuttered out something like "wait, this was pseudocode, I'm definitely not going to be able to make this run in the last 5 minutes," and they said something like "oh, OK" and wrapped up.

That was the entire phone screen, and they failed me. This still burns me years later because it was such an obvious communication failure on their part - if you're one of the rare interviews that actually require me to write working code, you better be darn sure to mention that upfront, rather than 5 minutes before the end of the hour! - and yet I was the one who failed.

Post reply on HN