Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.pragmaticengineer.com

Post reply on HN
Print view View original

301–310 of 547 posts

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

#301

Post by cmrdporcupine »

tchaffee wrote: post #115

This article is an excellent example of why most companies should never ask about algorithms in an interview. The author has worked for elite companies and yet even there he rarely had to reach something advanced. I've worked on some cool and really hard stuff in my career including cryptography and a popular Facebook app where my team used a graphdb, etc, etc, etc. And I would fail at most of today's interviews. For…

Thank you. I've been poking around the job market again after 10 years not searching, and it's disheartening. I have 20 years software development experience, I work at Google, I'm no spring chicken. I'm not the best engineer in the world, I'm sure, but I am a good programmer. I think I'd be an asset in many jobs. But I just turned down proceeding with interviews at a certain payment processing company because in part they wanted to give this kind of whiteboard coding interview. Our industry needs to give its head a shake.

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

#302

Post by MiroF »

notacoward wrote: post #294
syndacks wrote: post #284

Earlier quoted context omitted.

>Is any of that even controversial enough to require citation? I'm sorry, excuse me? Are you saying that non-minority, non-women don't suffer anxiety? Your parent comment certainly seems to suggest that. Which, at a minimum, is flat out wrong. Educate yourself[0]. And then zoom out and ask yourself why it's not only permissible, but often lauded, to so flippantly say what you just said. [0] - https://www.apa.org/abou…

> Are you saying that non-minority, non-women don't suffer anxiety? No, and I doubt anyone would have read it that way in good faith.

Good faith reader here, can confirm - you pretty clearly were only suggesting some general effect applying on average, not to every individual case.

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

#303

Post by jb3689 »

guidoism wrote: post #271

What is annoying about these interviews is that you are expected to have memoized all of the algorithms be able to implement them while someone is watching, on a whiteboard, in a very short amount of time. In my experience at Amazon and Google we all referred to books and colleagues when working through algorithms.

The grading rubrics for interviewers usually gives the candidate points for even mentioning particular algorithms, and I would hope that any decent interviewer would help you walk through trying to recall something. It's meant to be a design/application test, not a memory test

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

#304

Post by dekhn »

CydeWeys wrote: post #198

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 problems... who knows, something like... inverting a binary tree?

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

#305

Post by recursive »

Yajirobe wrote: post #291
Taek wrote: post #214

Earlier quoted context omitted.

Talking about code that someone has already written is missing the element of productivity. Since we pay you by the week and only get so many hours a week out of you, we need some way before we hire you to understand what type of output we can expect. The best way I know would be to work with someone for a week or two on a real problem, but that's way too expensive to trial a junior role. At least for us, the system…

Programming in an interview environment is completely different from programming at your 9-5 desk.

Everything else in an interview is also completely different from 9-5 engineering.

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

#307

Post by holidayacct »

karmakaze wrote: post #285
Drew_ wrote: post #276

Earlier quoted context omitted.

Technical interviews problems do sometimes actually resemble some discussions that happen in the real world however there are two major problems that I see in the interview space that don't have clear solutions: 1) one or two people in the discussion (interviewers) already know the perfect solution to the problem and are contributing as little as possible to the discussion. 2) the actual amount of allotted time to br…

> the only outcome is that more candidates would perform very well and that's not an outcome companies actually want unfortunately Why would this be the case--at places where the number of candidates far exceed positions? This is the exception rather than the common case.

Pick up a neuroscience book and you're going to quickly find out why your statement isn't possible. Have you ever had to conduct tech interviews or spoken to people who have? Tech interviews are the biggest crapshoot you'll ever see, for every 100 interviews you'll be lucky to find a single person who can code fizz buzz on the fly, introduce a small variation in fizz buzz that requires them to be able to read their own code and they can't modify their own code. The number of people who have a long enough short term memory and can concentrate on a single thing for three hours straight is exceedingly small.

Even the very best tech companies are constantly filtering through thousands of people who claim to have worked on extremely complicated development projects but can't code extremely simple things.

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

#308

Post by munchbunny »

As an engineer who works on security software, here's what I've empirically used on the job:

1. Tree/graph traversal (certificate validation and a couple other random places)

2. Using, not implementing, hash tables

3. Generators/iterators/streams: minimizing the number of unnecessary list traversals or allocations made when you have to shovel data around

4. Circular buffers: specifically in low latency, high throughput applications

5. Some exotic string search algorithms in a very specific, highly performance sensitive inner loop

6. Database query performance tuning

7. Every now and then something vaguely reminiscent of dynamic programming comes up, but it's never an actual dynamic programming problem, it's just a "cache results of expensive operations" problem.

For my job you need something exotic once in a blue moon, and when that happens you Google for someone else's research. You're not making up algorithms on your own. If you want to test that someone can handle algorithm-heavy situations like case #5, you should be testing their paper reading and ability to implement that paper, not their ability to solve an algorithms puzzle.

Also relevant to my job: if you find yourself implementing cryptographic algorithms, you're almost certainly doing it wrong. You shouldn't be implementing cryptographic algorithms. When I need them, my job is to vet and correctly use an expert implementation.

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

#309

Post by hajimemash »

CydeWeys wrote: post #198

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…

Thought experiment: If one were to make a very simple yet popular program, for what reason would that entitle them to a job somewhere? I'm having trouble thinking of one.

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

#310

Post by nogabebop23 »

Taek wrote: post #214
tchaffee wrote: post #78

Earlier quoted context omitted.

I already don't want the job because of the interview process. Talking to someone about code they have written and the decisions and thinking around their own code is so much more respectful and gives better signal. You should be doing everything you can to put the candidate on their own turf and letting them shine. I have a lot of advice about interviews but one of the best I've heard over the years: whatever impres…

Talking about code that someone has already written is missing the element of productivity. Since we pay you by the week and only get so many hours a week out of you, we need some way before we hire you to understand what type of output we can expect. The best way I know would be to work with someone for a week or two on a real problem, but that's way too expensive to trial a junior role. At least for us, the system…

>> The best way I know would be to work with someone for a week or two on a real problem,

So if I get the job will we just touch base ever week or so? This sounds unlikely. Why can't you break work down to the point that you can pay me for 3-4 hours of real output and then use that to evaluate my quality?

All these tests around recursion and linked lists, etc are a feel-good proxy for actually measuring suitability, If someone is actually implementing them (IF!) it's not the junior, new-person; it's the senior architect who does it once every few years in a shared library. I can count the number of times I've used recursion in (a) a non-toy implementation and (b) not ripped it out and replaced with a faster, clearer iterative implementation on one hand.

Post reply on HN