Live data from Hacker News

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

blog.pragmaticengineer.com

291–300 of 547 posts

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

#291
post #214

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…

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

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

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

> I say it works better, because it has the same asymptotic runtime [...]

To be fair, while the asymptotic runtime may be the same, the C version is about 180 times faster.

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

#293

Earlier quoted context omitted.

What is an IC? > isn't giving presentations to explain your ideas - sometimes to people you don't really know - actually a significant part of the job? For many engineering positions it is not. There are loads of shops where the developers, even senior developers, mostly just write code. I have hired many of them and put them to work successfully building stuff while I deal with the meetings. > If I were conducting a…

> What is an IC? Believe op is using it as "individual contributor"

Isn't there just a bit of condescension in that title? It always sounds to me like something invented by a manager to be dismissive of someone who doesn't manage anyone.

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

#294

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…

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

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

#295

Earlier quoted context omitted.

"write out these problems on paper" I write on paper so infrequently that I actually find it pretty difficult to write more than a few words. I certainly wouldn't want to write something out longhand in an interview! Edit: It seems to me it would be rather unfair of me to ask people to write out their thoughts in Org Mode in VS Code just because that's how I happen to like writing notes :-)

I had to do a timed exercise to write code on paper IN PEN at a job interview. Talk about feeling like I had to get it correct the first time. Glad they didn't give me an offer because I would've had to consider accepting it.

You problem used tabs rather than spaces ;-)

Seriously though - how long ago was that - not recently I hope?

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

#296
post #135

There's a huge distinction between "used" and "implemented myself". I've used quite a lot of features from RDBMs, as well as topological sorting, LRU for caches, Unicode normalization, graph traversal, bloom filters, hash maps and so on. I'm not payed to implement algorithms or data structures, but to solve problems. So for anything non-trivial I tend to use ready-made libraries. I only implement stuff myself when it…

You still have to understand how things are implemented by others (even at a high level view: ex: what is a RDBMS index) to be aware of their advantages and drawbacks to make the best use of algorithms available to achieve your goals (ex: performance of the solution, ease of evolution of the solution).

I agree. It's good to know a name of an algorithm/data structure, and rough characteristics (like bloom filter: O(1) lookup, super memory compact, statistical, can have false positives, no false negatives; perfect for caching lookups in "forbidden" lists).

There's not much point though in knowning the minutiae to the level that you can code one on the whiteboard without prior preparation -- which is probably the main point that the article relates to.

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

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

Have you tried just having a conversation about pointers and recursion? Does that not work as well (or better)?

Kudos for letting candidates know what’s going to happen, it’s just that when I see problems that are clearly just a stand in for “do you know X?” I always wonder why interviewers don’t cut to the chase and just ask directly. “Are you comfortable with recursion? Can you describe it? When does it tend to be applicable?”

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

#298

There's a huge distinction between "used" and "implemented myself". I've used quite a lot of features from RDBMs, as well as topological sorting, LRU for caches, Unicode normalization, graph traversal, bloom filters, hash maps and so on. I'm not payed to implement algorithms or data structures, but to solve problems. So for anything non-trivial I tend to use ready-made libraries. I only implement stuff myself when it…

And this is the measure of a good engineer -- recognizing that it's most likely that battle tested libraries will have superior implementations of algorithms than whatever one can draw up oneself.

I use the STL daily. I know fairly well the complexity guarantees behind each data structure. That's one of the things I like about it versus other collections libraries. It forces you to be somewhat literate on data structures in order to make the right choices.

But no, I could not write you up a red-black tree from scratch without going away for a few days with my Knuth books and a few pots of coffee. Sorry.

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

#299
post #240
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…

Algorithms and Data Structures don't measure either of those things. General IQ is not measured by very specific technical problems. Nor is learning something specific an indication of "grit". It's a proxy for interviewers to jerk their ego.

Answering data structure/algorithm questions is absolutely meant as a measure of grit. It takes perhaps hundreds of hours of leetcode grinding to be able to quickly answer any problem which might come up in an interview. The point is to find out how committed applicants are.

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

#300
post #54
post #41

Earlier quoted context omitted.

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

It's a great showcase of how a flashy looking solution is the wrong approach. A good candidate will know it can be written in 2 lines recursively, but that the stack will explode with a fairly low term number, and that iterating with a for loop is more efficient.

Or in this case, just compute it from the closed form expression with no loop at all.
Post reply on HN