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

#321

Post by tsumnia » Wed, Jul 15, 2020, 4:28 PM UTC

ipnon wrote: post #316

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…

I call this distinction red flag versus green flag interviews. The typical hiring process is looking to quickly disqualify all but 1 person in the hundreds of resumes submitted to any open software engineering position. The hiring process you are proposing is looking to methodically search for all of the useful qualities in the candidate pool and determine how they can best be applied at the company. I think we can a…

> I think we can all agree someone can be a poor software engineer and not have any red flags.

This has been something I find myself musing over every now and then for a couple years now. As we begin to relax barriers of entry, how do we maintain that some people fail/lose?

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

#322

Post by Darvon » Wed, Jul 15, 2020, 4:31 PM 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,…

I'd hate working alongside a young anxiety free conformist who doesn't have external commitments.

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

#323

Post by wenc » Wed, Jul 15, 2020, 4:37 PM UTC

notacoward wrote: post #273

wenc wrote: post #264

Earlier quoted context omitted.

> Resistance to anxiety. This disadvantages women, minorities, and people with psychological conditions that should be covered by ADA. I resemble some of those categories, and I don't know if I would feel comfortable making the leap to correlate them to a some inherent reduced level of resistance to anxiety. That seems like a generalization which I feel that, on an aggregate level, seems unsupportable by data. I thin…

Allow me to elaborate, then. There's an inherent power dynamic in interviews, which creates stress in the interviewees. That effect is magnified for anyone who is unlike their interviewers, who still tend to be white and male. It's magnified still further when the power dynamic within the interview reflect the one that - very unfortunately - still persists in society at large. Lastly, the funny thing about stress/anx…

I can see what you're saying (in good faith). I do think interview anxiety is a collocation of multiple factors. I don't think the correlation of anxiety to the listed categories are easily deconvolved from other factors -- it might seem like a common-sense correlation, especially if you start from certain priors, but it's a big assumption to make on average.

(Only this past week I had experiences that challenged my assumptions about certain demographics (seniors) and how I would expect they would behave, and how they actually behaved. The lesson I learned was -- don't assume, always collect real data)

The white-male interviewer power dynamic has some basis in reality (I've experienced it occasionally, not all the time), but its effect on my interview performance may be less than 10%? (to throw out a number). I find I'm much more affected -- maybe 90% -- about (1) my competence in the subject matter and (2) how well practiced I am (for instance, I know the theory for a great many subjects but am unpracticed at some of them, so I tend to stumble and lack ease when it comes to demonstrating my subject matter knowledge in real time).

For different people, those percentages shift, and I believe in a way that is not obviously or necessarily correlated with their demographic (psychological conditions, yes, but also depends on which ones -- some don't affect anxiety). But all I have is anecdata so I'm not able to provide strong evidence one way or another so this is just my two cents worth -- and I do mean this in good faith.

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

#324

Post by shecky » Wed, Jul 15, 2020, 4:42 PM 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…

> 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

where have you been all my life? ;)

I'm an autodidact, zero formal bg in comp sci. I suck at timed tests and algo interviews. Fifteen years I've been at this and I've worked with several 'full stack' teams, none of which had a single engineer who was within a thousand miles of what I could do with CSS (and they're mostly utter slobs wrt HTML). And as to the endless javascript demands, I will never be of interest to google (and the feeling's mutual) but I always get the job done, and often the job is something FE that none of my esteemed colleagues would know the first thing about how to achieve, comp sci degrees and recursion expertise notwithstanding ... not to mention that every one of them has as many stack overflow tabs open as me.

I'll get back to my sorry little js projects now, maybe I'll get another job before I grow old and die ;)

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

#325

Post by _urga » Wed, Jul 15, 2020, 4:42 PM UTC

Where things get interesting is the mismatch between Big-O data structure complexity analysis (as typically discussed in interviews) and actually knowing about the hardware, the operating system, the memory hierarchy and things like cost of context switches and cache misses.

Some real-life practical examples: knowing when a simple O(n) linear search beats O(log n) binary search, or knowing when a multiple substring search algorithm based on a simple Rabin-Karp and L1 cached hash table lookup will outperform the theoretically more optimal Aho-Corasick.

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

#326

Post by ahel » Wed, Jul 15, 2020, 4:43 PM UTC

decafninja wrote: post #256

I don't think the issue is DS&A or even leetcode problems in general. I think the problem is being expected to regurgitate* 1-2 hyperoptimal leetcode solutions in 45 minutes while suffering from heavy interview pressure. *by regurgitate, you can't simply implement the optimal solution either even if you know it. You have to put on a show where it seems like you're arriving at and iterating towards the optimal solutio…

> Recruiters and official interview guides say that your "thought processes" matter a lot, but reports from in the field tend to imply that the #1 most important factor is that you get the optimal solution. If you can't, your "thought processes" are worth little, barring exceptional circumstances

Agree. Also "there is no hard requirement in completing both part of the exercise" is another lie.

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

#327

Post by jkingsbery » Wed, Jul 15, 2020, 4:44 PM UTC

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. The interviewer didn't like this, so he said "Pretend you're an engineer at Google. You need to have a convex hull. What do you do?" And I said probably the most correct thing I've said in any interview: "I would go look it up." He really didn't like this answer, but we struggled together for an hour, with him frustrated that I couldn't remember the details of an algorithm I last had seen 6 years earlier and couldn't recite in 60 minutes what took our professor 180 minutes of lectures to cover, and me frustrated that would have taken me 30 seconds to look up.

I did not get the job at Google.

I do make sure as a more senior engineer at my current company I use what leverage I have to make sure other interviewers don't ask pointless questions like this.

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

#328

Post by FiberBundle » Wed, Jul 15, 2020, 4:47 PM UTC

ourlordcaffeine wrote: post #185

nostrebored wrote: post #137

Earlier quoted context omitted.

This was the focus of my advanced algorithms course at Georgia Tech in my senior year. We had basically a full semester on random algorithms, and I remember walking out each day feeling like the fancy algorithms I'd memorized the previous year were a bit less glamorous. The number of algorithms that removed multiple complicated stateful steps with 'and we randomly select an element from the array' was mindblowing. As…

Do you know any good books or resources to read up more on random algorithms?

Probability and Computing by mitzenmacher is a very good book

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

#329

Post by harha » Wed, Jul 15, 2020, 4:53 PM UTC

munchbunny wrote: post #308

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

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 was my experience at Google compared to the usually more interesting people I worked with at university.

It’s just more difficult to test beforehand how someone might actually solve a problem in a good way as you describe. If applicable it’s possible to look at prior work, if you have any other good ways I’d be very interested.

Edit: this is actually a good thread to get some ideas on improving interviews.

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

#330

Post by oblio » Wed, Jul 15, 2020, 5:00 PM UTC

syndacks wrote: post #284

notacoward wrote: post #273

Earlier quoted context omitted.

Allow me to elaborate, then. There's an inherent power dynamic in interviews, which creates stress in the interviewees. That effect is magnified for anyone who is unlike their interviewers, who still tend to be white and male. It's magnified still further when the power dynamic within the interview reflect the one that - very unfortunately - still persists in society at large. Lastly, the funny thing about stress/anx…

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

You just "All Lives Matter"ed his "Black Lives Matter" argument.

And I'm not writing this as praise for your comment...