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

311–320 of 547 posts

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

#311

Post by nogabebop23 »

TedDoesntTalk wrote: post #191
haggy wrote: post #150

Earlier quoted context omitted.

I agree with this 100%. I'd also like to add that because of this I adapted the traditional whiteboarding exercise at my current company to be about problem solving and design, and not about how many data structures you've memorized. When a candidate comes in, I give them a fake-yet-realistic product requirement (like count elements in a real-time stream from field sensors) and let them run with it however they see f…

I do something similar: I ask the candidate to take 30 minutes or so to design a system like an online library. What are the objects in the system, how do they relate, can you design a REST or graphQL API for CRUD operations. Then if it’s a front-end position we can move onto UI components for it; for back-end or full stack I focus on implement a couple of the CRUD operations. You really get to see how people think a…

>> You really get to see how people think and will work on the job with questions like this.

Interviewing is hard and I applaud you for trying something newer and more realistic but I'd be cautious in thinking "spend 30 minutes designing a system and be prepared to defend your work with massive risk/reward hanging in the balance. Begin... NOW!!!!" is representative of how someone will work on the job. There are an awful lot of people who will solve the crux problems driving home after the interview or the next morning in the shower vs. on-demand.

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

#312

Post by hackinthebochs »

midev wrote: post #240
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…

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.

IQ is a measure of mental flexibility independent of context. Being able to solve tricky algorithm problems is a measure of mental flexibility in the context of programming. The two are strongly correlated. Of course, the test is confounded by a baseline of programming and CS knowledge.

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

#313

Post by redblacktree »

fatnoah wrote: post #275
kypro wrote: post #160

Earlier quoted context omitted.

I agree. I really dislike being asked to produce code of any complexity in an interview setting, although I do think it's important to see a candidate's code to understand how they solve problems for more senior roles. Personally I'm way too anxious in interview settings to produce decent code. In interviews I find myself trying to get everything right first time, but in reality that's not how I work. I prefer to dev…

>I agree. I really dislike being asked to produce code of any complexity in an interview setting, although I do think it's important to see a candidate's code to understand how they solve problems for more senior roles. I've never been a big fan of giving code interviews, however when I have to give them, I'm far more interested in the candidate's thought process around how they understand the problem and what needs…

I agree, and I think this is where the value in these kinds of interview techniques lie. As the interviewee though, I have to say that the high-pressure situation makes me feel very... exposed(?) when I have to elucidate my thought process in real time.

I will say that one of the best "interviews" I've had included a portion where I worked with one of their engineers on a design problem they were actually having. It felt very collaborative, which allowed me to relax a bit, and I think we came up with a pretty good solution. I didn't mind doing "free work," because for me, it's fun to solve problems like these.

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

#314

Post by chadash »

> The most frequent data structure I've used regularly was hashtables and the hashing function. It's such a handy tool from counting, to detecting duplications, to caching, all the way to distributed systems use cases like sharding. After arrays, it's easily the most common data structure I've used on countless occasions. Almost all languages come with this data structure, and it's simple to implement if you'd need it.

I'm surprised this wasn't listed first. I always ask a question or two related to hash tables when I interview candidates and I'm continuously shocked that a good chunk of candidates don't know the basics of hash tables. I expect you to know that looking up whether an item exists in a hash table is _generally_ fast in practice, even if you don't know the specifics of O(1) best case, O(n) worst case. I expect you to know that it doesn't allow duplicate keys. I don't expect you to implement a hash data structure from scratch, but I do expect you to know which data structure implements a hash table in your language of choice (e.g. Object, Dictionary, Map, etc.).

It's the one slightly more complex "data structure" that I use all the time, so it's surprising to me when people don't know the basics.

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

#315

Post by munchbunny »

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…

That's explicitly the stated reason I've gotten from people I know who use algorithms/data-structure interviews.

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

#316

Post by ipnon »

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 all agree someone can be a poor software engineer and not have any red flags.

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

#317

Post by mikorym »

ajuc wrote: 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…

> It was a highlight of that month.

Just using a graph was the highlight of that month for me. (The data wasn't already in a graph.) Reading the wiki, it may have been Dijkstra that I used under the hood. (I just wanted the sum of simple paths for all leaves to the root, for each leaf.)

Cheers for us.

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

#318

Post by jcranmer »

Working on compilers, graph algorithms of various kinds tend to come up rather frequently. The only one that I recall having to implement myself was enumerating elementary cycles in a graph. That said, you often have to do a modified standard tree or graph traversal, so some variant of BFS or DFS is pretty common.

The only other exotic data structure I've had to use is the union-find data structure. It's a pretty slick data structure, both because it's so easy that you could probably come up with the optimal one just by thinking about it for a few hours, but also because its runtime is O(n * inverse Ackermann(n)), the latter function grows so slowly that it is less than 4 for the number of atoms in the universe. Although, unfortunately, the data structure doesn't do a good job of telling you which union call is the one that merged two sets that should be separate together.

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

#319

Post by VRay »

arethuza wrote: post #293
unclewalter wrote: post #181

Earlier quoted context omitted.

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

I think you're projecting

I've never heard of someone not liking the term "Individual Contributor" before

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

#320

Post by giantrobot »

TedDoesntTalk wrote: post #196
yahyaheee wrote: post #184

Earlier quoted context omitted.

That’s not the same as on the spot coding challenges in a whiteboard though

You’re right. But what are you trying to prove with on the spot coding challenges? That the candidate can implement a hash table from scratch in 15 minutes with O(1) performance? Is that something they’re going to do on the job? Very unlikely. So why are you not only testing for it but testing for it in a fake time-pressured stressful situation that also rarely exists on the job? (Yes , we all have deadlines but when…

People giving on the spot coding exams, or worse whiteboard coding exams are just assholes. They're trying to haze interviewees and make themselves feel better. There's zero actual utility to such tasks in an interview.
Post reply on HN