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

81–90 of 547 posts

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

#81

Post by fenomas »

ajuc wrote: post #67
arethuza wrote: post #40

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 :-)

Writing speed isn't the bottleneck hopefully :)

It's not a matter of writing speed, it's familiarity. I've been programming for 30 years and I don't think I've ever written code down on paper. Why ask an interview candidate to do something they've never done before and will never do again? You might as well ask them to type their code using only one hand.

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

#82

Post by rimliu »

WalterBright wrote: post #72
rimliu wrote: post #69

Earlier quoted context omitted.

If you use recurssion for Fibbonacci, you do not understand neither recurrsion nor Fibbonacci.

"You, Sir, are employing a double negative." -- Mr. Spock

Am I?

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

#83

Post by colordrops »

Many software engineers do indeed go for long periods without using anything but the most rudimentary algorithms. Needing to know or at least be familiar with many complex algorithms is more of a broad specialty now, and you get shunted into different sorts of work depending on your knowledge of algorithms.

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

#84

Post by arethuza »

ajuc wrote: post #67
arethuza wrote: post #40

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 :-)

Writing speed isn't the bottleneck hopefully :)

Writing speed probably would be the bottleneck for me - plus whatever I wrote would almost certainly be illegible to anyone else.

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

#85

Post by OptionX »

Is there any resource, either online, print of any other form, that lists many data structures in a ordered, searchable manner? Something close to a dictionary or compendium that you could, for example, search what data structures had better performance for the search of an element, or insertion/deletion of an element, stuff like that. I learned the basics ones in uni, but I still find many new (new to me anyway) ones, mostly at random, I wish I knew. Most books on the matter that I read don't go much beyond the basic set of most common ones either.

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

#86

Post by bananaface »

I don't like algorithms as an interview structure but I do think they have one property that people way underestimate. Algorithms test your ability to manipulate a complex problem in your head without being able to break it down.

Most coding problems can be broken apart and the individual components tackled one by one. But that has two problems. One, it doesn't stress-test the programmer. Two, the most beneficial changes to a codebase come from a high-level understanding of the system. Implementation might be segmented, but the more of the system you can simultaneously understand & manipulate in your head, the better placed you are to manipulate the architecture.

Complex algo questions force you to manipulate a fundamentally complex problem. You can break it apart in some ways, but in general you have to be able to think about the entire basic algorithm in your head. Reversing a binary tree? You have to be able to visualise the datastructure you're manipulating and figure out what changes you need to make before you start writing. It's a stress test, it tests horsepower.

Granted, you can game that system by doing practice questions which undermines it to an enormous degree but I'm not sure what else you can do to test that.

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

#87

Post by zodiac »

kristopolous wrote: post #32

Let's say someone can solve the algo problem, what's that show? Mostly that they prepared for an algorithms question. It may be a good filter for 3rd-wave do-as-you're told programmers who stay in their lanes, produce by the book expected code, and just consistently obediently build things. They wan better cogs for the corporate software machine. If people are asking me algo questions, the job probably isn't right fo…

What does this have to do with the bulk of the article (which is about algorithms the author used at his jobs, and only tangentially (IMO) about the use of algorithmic questions in interviews)?

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

#88

Post by dotancohen »

eru wrote: post #59
bbarn wrote: post #54

Earlier quoted context omitted.

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.

In eg Python you can just add a memoization decoration, and get a linear solution from the naive recursive one. That's pretty neat.

In almost any language, a hashtable check after the base case check could be used in a similar manner.

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

#89

Post by gabrielhora »

The main problem, I believe, is the time constraint and the interview environment, both add a LOT of stress and will reduce our ability to come up with an answer. I think most people can come up with a good algorithmic solution given the proper time to do so.

IMHO take home tests with a following discussion of the solution is the best way to go. Interviewers can judge the code quality as well as critical thinking with the follow up discussions.

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

#90

Post by tchaffee »

wadkar wrote: post #61
deadgunslinger wrote: post #53

Earlier quoted context omitted.

How do you figure from a Fibonacci exercise that the candidate understands recursion? It's 5 lines of code to memorize.

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 for if I had to use recursion again. This is why the interview process is broken. I've written lots of production code and end up being seen as a lead programmer within weeks of a new job. And your questions would make me look like I don't know what I'm talking about.
Post reply on HN