Live data from Hacker News

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

blog.pragmaticengineer.com

241–250 of 547 posts

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

#241
post #22
post #10

I've used Dijkstra algorithm for calculating distance in a graph once. It was a highlight of that month. Of course I had to look it up(despite learning it and implementing it at university). Who remembers this stuff exactly after years of glueing libraries together? And even if you remember - won't you check it anyway just to be sure? It's OK to ask people general questions (what's algorithmic complexity, what kind o…

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…

Seems over-complicated, e.g. I probably wouldn't go for recursion for Fibbonacci, so I'd miss your expectations completely. Why not just ask a direct question on things that you're looking for? If you care about recursion, ask them to implement simple recursive tree walker or something. Equally linked lists are something that in modern languages almost no one will have to manage by hand. If you care about understanding the concept of pointers/refs, why just not asking directly about that.

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

#242
post #41
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…

Why would anyone use recursion to calculate Fibonacci numbers other than as a microbenchmark for function call performance?

For Fibonacci, recursion is not the best or most efficient way to approach the problem, but I like using it as a recursion problem (artificially constrain the candidate to using recursion) because Fibonacci is so simple that you get to spend most of your time talking about recursion itself rather than talking about Fibonacci as a problem.

At least for this part of the interview, I'm not worried about your problem solving skills I'm worried about your programming fundamentals. We'll test problem solving in a different session.

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

#243
post #164
post #141

Earlier quoted context omitted.

In practice iteration will be faster, even in Python (because there's less overhead). But yes, I should have written "naive recursive solution". There are many ways to fix it. It just wasn't what the question was about.

In Python, yes. If you have a decent language and a good compiler / interpreter, then the recursion with function calls will have no overhead over iteration. (Basically, in Haskell or Scheme your recursion will be compiled into the same machine language sequence of straight-line code plus conditional jump as the iterative loop.) But, agreed with everything else you wrote!

>(Basically, in Haskell or Scheme your recursion will be compiled into the same machine language sequence of straight-line code plus conditional jump as the iterative loop.)

This is not true. The recursive code will not compile with zero overhead even in haskell or lisp.

  fib :: int -> int
  fib 0 = 1
  fib 1 = 1
  fib n = fib (n - 1) + fib (n - 2)
The code above will add layers to the call stack and has a speed complexity of O(N) and memory complexity of O(N).

To optimize in Haskell you need to deliberately restructure your code.

  fib :: int -> int
  fib n = let _fib 0 a b = a
              _fib 1 a b = b
              _fib n a b = fib (n - 1) b (a + b) 
          in _fib n 0 1
The above code will have O(N) speed complexity and constant memory in Haskell. In order for Haskell or any language with tail recursion optimization to work the recursive call must take up the entire return expression. In short the coder must deliberately make optimizations and write recursion in a way similar to the original iterative syntax in order for such tricks to work.

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

#244
It's like in any competitive exam where there are too many candidates and not enough positions. If you ever look at the type of math and science problems on Chinese university exams they are not necessarily advance in terms of the topic but they are extremely tricky. A electromagnetism question testing your knowledge of Gauss' law usually in a regular setting would use a charged sphere or some other object with geometric symmetry you can take advantage of. I have seen one question where it involved Gauss' law around the corner of a pipe (the elbow part).

It's just an exercise to see "how badly does this guy want it? how much did you cram?" Like hazing.

As an anecdotal story, I once interviewed at a well known HFT in Manhattan, after jumping through the phone screen and timed coding interview (involving four questions), you were invited on site. The first thing you do on-site (10 am in the morning) is take a 2 hour multiple choice exam consisting of 100 questions and get this - it was literally on scantron card, so they can score it right away (exactly how I used to multiple choice exams in high school).

If they didn't like your score, you were sent packing right away, otherwise the real interviews would begin with actual people throughout the afternoon. Allegedly, the way you knew this was, if you they asked you what you wanted to lunch, that meant you passed and could go to the one-on-one interviews.

I didn't get the job in the end, but I did get a ham sandwich and soda out of the deal.

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

#245
post #97
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…

Due to the physical architecture of CPUs/etc., data structures that have "worse" asymptotic performance are often quite a bit faster than those with "better" performance. For example, iterating through a small array to find an item and test for existence is often quite a bit faster than using a hash set for the same operation.

Which is why I just use the standard library.

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

#246

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…

I agree, but how is applying pre-learned algorithms significantly better than using pre-build libraries? Both is about using an existing solution, instead of coming up with it on your own. The real approach would be to ask candidates to solve a problem that doesn't easily fit into any popular category, so that they have to come up with an original approach - but that is first hard to come up with, and 2nd it would require investing extra time on both sides, which usually neither candidates nor interviewer can afford.

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

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

Depending on how you conduct them, they are actually stress tests:

https://medium.com/@gameweld/the-case-for-the-private-techni....

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

#248
post #127
post #100

Earlier quoted context omitted.

Something like this (might be subtly wrong, I wrote it in 2 minutes). int fib(int n) { if (n vs recursive solution which is pretty but slow (and will fail when you run out of stack) int fib(int n) { if (i

Of course, recursion vs iteration is mostly an implementation detail. Here's a recursive version (expressed in Python) that works better than your loop: def fib(n): if n = (I say it works better, because it has the same asymptotic runtime, but fails better: When numbers get large, your C version will run into undefined behaviour that can cause arbitrary problems. The Python version will just crash with a well-defined…

For the code above memory complexity is still O(N) even in a language that optimizes for tail calls. This occurs because you have an additional expression that occurs AFTER your recursive call that means the system must hold everything on the call stack for it to work.

Additionally you have a spelling error on line 5.

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

#249
post #236
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…

- Retention. If this person spent hours on leetcode, they’ll be less likely to leave the job knowing the effort it takes to get through the gate

[deleted]

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

#250
post #61

Earlier quoted context omitted.

By the way they discuss the implementation. First level is ensuring that base cases are covered (i.e. correct implementation of recursion) Second level is how they explain the simple recursion that’ll hit stack limits (i.e. without tail recursion) Third level is using accumulator/tail recursion. See how they can express these ideas and are they able to effectively communicate their intentions.

In my decades of programming I've never had to seriously consider these issues. I have used recursion and have written some pretty deep stuff like cryptography and writing my own interpreter (for a business - not a school project). I've even implemented recursion in a language that didn't support it. I have read about tail recursion several times. I still barely remember what it is. But I know a few books to reach fo…

[deleted]
Post reply on HN