Data structures and algorithms I actually used while working at tech companies • Hacker News Board

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

#461

Post by dogfoods » Thu, Jul 16, 2020, 3:21 AM UTC

dragonsngoblins wrote: post #448

Swizec wrote: post #411

Earlier quoted context omitted.

Funnily that old style of question is far closer to my day-to-day as an engineer than a leetcode algorithms question. Most of my job involves figuring out solutions to fuzzy problems based on unknown constraints, undiscovered requirements, and often unclear end-goals. "How would you fill this airplane with golf balls?" is a fantastic question. If the candidate doesn't reply with "Why? What are you really trying to ac…

I suppose it depends on how you grade the answers. Like I have bad spatial awareness in terms of how big things like planes are. I genuinely don't really have an idea how long a commercial airliner is, or how big a ping pong ball is. I feel like I'd do ok if I could get reasonable approximate values for things like the size of the plane, the balls, the seats, etc. if I also have to supply those values myself the end…

Commercial airliners vary in size more than an order of magnitude anyway. There are commercial aircraft that are shorter than an A380 is tall.

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

#462

Post by dabraham1248 » Thu, Jul 16, 2020, 3:32 AM UTC

chrisseaton wrote: post #361

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…

I think people forget how incredibly high the Google hiring bar is. Tons of people have written extremely successful software, but I think you really need to be at the very top of your field to even be considering going to Google. You can be absolutely excellent... and still not be good enough for Google, and it's fine to admit that.

I've known too many people who work at Google to agree with this. They've hired some people who were just plain incompetent, some who were great, but mostly in the middle, much like every other company.

TBF, they do seem to have more than their share of great, but, not by a lot...

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

#463

Post by treebog » Thu, Jul 16, 2020, 3:42 AM UTC

bjourne wrote: post #401

Swizec wrote: post #392

Earlier quoted context omitted.

"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?"

I'd let the material science engineer figure that one out too. No way in hell would I risk my ignorance of building maintenance be the cause of thousands of deaths.

One thing I learned in getting my engineering degree is that it’s unethical to practice engineering in an area you don’t understand. No way would I ever try to apply my software engineering skills to a materials problem

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

#464

Post by ricksharp » Thu, Jul 16, 2020, 3:43 AM UTC

tsimionescu wrote: post #220

ricksharp wrote: post #193

Earlier quoted context omitted.

This sounds like an inspection of whether the person has had a class in basic algorithms rather than if they have ever coded anything in real life. In school I played with sorting algorithms, in business if I ever found a developer manually writing a sorting algorithm, I would consider them inept (unless there were very specific reasons to do so). If someone didn’t know how to sort a list using the built in or standa…

If you're given a blank slate and asked to sort a list without using a library without any gotchas, complexity requirements, space requirements, expectations that the code is completely free of small bugs etc.; and you can't do that after some thinking even to a basic degree, then you're just not a good programmer. As a programmer, your task is to find algorithms to solve problems. Sure, sorting numbers is a solved p…

My point was that if testing for a skillset, using something that favors those who have toyed with a specific algorithm is the same as asking trivia questions.

Trivia does not provide evidence of skill, it demonstrates prior knowledge.

It would be better to introduce a unique situation that would place everyone at the same starting point.

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

#465

Post by dogfoods » Thu, Jul 16, 2020, 3:52 AM UTC

entha_saava wrote: post #80

p1necone wrote: post #68

Earlier quoted context omitted.

In my experience it's pretty necessary to do this. Probably depends on your local job market, but there are a shocking number of candidates that just don't know how to code. The explanation I've heard is that good devs generally get hired after only a handful of interviews, whereas really bad devs are going to do a lot more interviews on average before they get hired, so you get a pretty skewed sampling even if there…

Yes, Joel Spolsky and IIRC Jeff Atwood have written somewhat extensively about it. We are in a bubble, if we read programming blogs and think about programming in our free time, we are definitely not the kind that FizzBuzz exists to filter out. But from the perspective of companies, it makes sense if they really understood pointers or recursion or graph manipulation, because there are so many people lying on their re…

Real jobs have certificates and degrees that mean something, where you can avoid the whole "do you know literal 101 things" phases of the interview process by just going "do you see the line on my resume that says M.Sc."

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

#466

Post by Aperocky » Thu, Jul 16, 2020, 4:00 AM UTC

eru wrote: post #64

A few years ago I spend lots of time and effort at Goldman Sachs solving a performance problem in a major part of their internal cloud infrastructure. The programme in question was running into performance problems, and a few smart people had already banged their head against a wall solving them. After lots of experiments and different approaches, my solution was to remove most of the advanced data structures that we…

Nested loops go brrrrr

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

#467

Post by ajzinsbwbs » Thu, Jul 16, 2020, 4:34 AM UTC

tchaffee wrote: post #78

Taek wrote: post #22

Earlier quoted context omitted.

We always tell our candidates in advance what algorithms we'll be quizzing them on. And it's pretty much always: + fibbonacci + a sort + a linked list I like having candidates write out these problems on paper because it shows that they know how to think about code. Fibbonacci allows us to see that they have basic recursion understanding, and basic iterative loop understanding. Linked lists shows us that they underst…

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…

How to filter out candidates who are only good at talking? I’ve worked with people like that and it’s miserable.

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

#468

Post by ajzinsbwbs » Thu, Jul 16, 2020, 4:54 AM UTC

notacoward wrote: post #257

whack wrote: post #228

I'm increasingly convinced that Algorithms-and-Data-Structure interviews are essentially being used as a proxy for: - General IQ. Can this person understand and apply complex ideas - Grit. Is this person hard-working enough to learn things that take time and effort It's the software equivalent of the NFL scouting combine. The goal is not to create a test that is similar to the day-to-day job. But rather, create a tes…

Unfortunately, those kinds of interviews also select for some other things that they shouldn't. * Youth. People who have very recently studied these things in school, and use the same languages as the interviewers, have an advantage. * Free time. People who have families (for example) might have less free time to study "Cracking the Code Interview" and such. * Absence of anxiety. This disadvantages women, minorities,…

What if qualities you might judge in an interview other than “general IQ” and “grit” are even more bias-prone, and using those other qualities is actually worse than measuring “general IQ” and “grit” and applying a corrective factor?

In other words, I’d rather work with a disadvantaged person who may appear rough around the edges but made it this far and has the “general IQ” and “grit” to do well on the programming problem, than the preppy white kid who has a lifetime of experience preparing for the task of exuding status and competency when answering behavioral questions or engineering case studies, but lacks the “general IQ” and “grit” to solve the programming problem.

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

#469

Post by kortilla » Thu, Jul 16, 2020, 5:18 AM UTC

dogfoods wrote: post #461

dragonsngoblins wrote: post #448

Earlier quoted context omitted.

I suppose it depends on how you grade the answers. Like I have bad spatial awareness in terms of how big things like planes are. I genuinely don't really have an idea how long a commercial airliner is, or how big a ping pong ball is. I feel like I'd do ok if I could get reasonable approximate values for things like the size of the plane, the balls, the seats, etc. if I also have to supply those values myself the end…

Commercial airliners vary in size more than an order of magnitude anyway. There are commercial aircraft that are shorter than an A380 is tall.

The fuselage of a 737 is the same diameter as the engine of a 777.

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

#470

Post by jcranmer » Thu, Jul 16, 2020, 5:24 AM UTC

Swizec wrote: post #402

JakeStone wrote: post #394

Earlier quoted context omitted.

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.

> Use to build a wall around the city? That sounds expensive. Do we need to do that? Does it solve the problem better? Does it maybe create a worse solution? How would you find out? > Have the people who maintained each individual building form a team that can keep an eye on sections in shifts? How would you make this less time intensive? Can you use automation? > If we have enough magic material, build a double wall…

I can't tell if you're asking these questions to elicit a longer discussion, or if you are doing so because you don't like the idea of a simple solution.