Live data from Hacker News

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

blog.pragmaticengineer.com

371–380 of 547 posts

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

#371
post #333

Earlier quoted context omitted.

What's wrong with a memoized recursive solution? Or a DP tail recursive solution? Tail recursive solutions are less buggy, easier to code, and easier to write than iterative ones. And they're much easier to prove the correctness of as well.

The memoized recursive solution is a good demonstration of how to use memoization to improve recursive function execution time. But it also seriously increases the memory requirements for many algorithms. If the question is "generate the first N numbers in the Fibonacci series", then memoization is a reasonable answer (though still not the fastest) since you actually need to generate and store every value anyways. If…

If the question is "generate the Nth number in the series", I would be inclined to suggest a closed-form solution that returns in O(1) time (assuming regular size integers), no iteration required.

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

#372

Earlier quoted context omitted.

IMHO, this is not particular better than an algorithm question. Why not just summarizes the traits of the technical skills you expect from the candidate, lay it out, and come up appropriate questions for each interview? General software engineering interview does not work. But there can be more specific measures to improve the experience.

> Why not just summarizes the traits of the technical skills you expect from the candidate, lay it out, and come up appropriate questions for each interview? That won't work; it's aimed at a different kind of skill. The skill the GP is looking for is ability to solve a problem you have never seen before, for a problem that bears little resemblance to anything you've done before, by transferring your existing general…

> It's a test of your ability to solve new things, which is a capability the company finds useful.

Correct.

I work with early-ish stage startups. There's always a library that solves any given known problem. We don't have the scale or nuance to need to reinvent the wheel.

Where I really need engineers to shine is in solving the parts that don't have a library because we've stumbled onto something new. Or at least something new to the team. Or the way we've cobbled libraries together creates something new.

The important work is the work you haven't done before. We're engineers not line cooks.

November should involve completely different work and a whole new set of problems than February. If you're still doing the same thing you did in February, something's gone wrong.

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

#374
post #341
post #336

Earlier quoted context omitted.

Yea I interview (and have sat on HC) at Google, and interviewers who ask these types of questions really frustrate me. If your question requires having previously memorized or being able to come up with some tricky algorithm on the fly in 45 minutes and code a solution using it , your question is probably bad. I get why they ask them - they're easy to ask, they're easy to score, and when your question inevitably gets…

My favorite question to ask in software engineering interviews is one that I believe to be un-burnable. > It's 2140 AD, New York is under water up to X feet high. Buildings have been retrofitted with to withstand the water. You are in charge of keeping your building dry. If water gets in and damages the foundation, a few thousand people die or become homeless. > Design a system that ensures that doesn't happen. How c…

I would love to ask questions like that. I'm pretty sure hiring committee would not like it though lol.

I do worry about asking questions that give candidates extremely large advantages if they have certain backgrounds. For example someone coming from mech, civ, or petroleum engineering will get a huge leg up on that question.

It is also worth noting that the structure for interviewing at a company with 30-50k+ engineers is different than the structure you need for interviewing at a company with <<1k engineers.

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

#375

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

Your story reminds me of when I interviewed at Google and did great on four interviews but the fifth one sunk me. I was asked an inheritance question which didn't make much sense (coming from a heavy Perl and Ruby background) but probably would have made more sense if I were a heavy C++ developer. I explained how the question wasn't really an issue in Ruby but the interviewer didn't like that and angrily said "you should have learned this in your compilers class at Georgia Tech!"

I'm glad that the interviewer read my resume closely to learn my alma mater, but not closely enough to realize I had a biology degree from it.

I tried again a year later and got luckier with my allocation of interviewers. I never did end up using any algorithms there.

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

#376

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.

It depends on the culture setting.

If you're in a place where an IC can potentially make half a million or million dollars a year and drive some very interesting project work and be highly respected, no.

If you're in a place where not making it into manager track puts a very low ceiling on earning potential and respect, then yes it can be condescending.

This varies a lot by country, industry, etc.

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

#377

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

Another anecdote of an incompetent interviewer blindly looking for a certain answer:

I once had an interview where, for a pretty long question, one trivial step was to check that one set was a subset of another set. Neither set had any special preconditions, just two plain unordered Java HashSets. Not thinking twice about it, I wrote a simple for loop that checked if every element in the smaller set was present in the bigger set.

When I finished the question, the interviewer started questioning me about the runtime of the for loop. He started hinting that it could be more efficient, which confused me, since it seemed impossible to check every element of a set in faster than O(n) time. I also didn't see how it was useful to think so carefully about the runtime of such a trivial thing, seeing as the "story" of the problem indicated that the sets would never be particularly large and the task wasn't one that would be sensitive to a couple microseconds difference in runtime.

We spent about 20 minutes stuck on this, with me awkwardly repeating I didn't see how it was possible to be faster and him telling me to just think harder and look at the problem "mathematically", "forget about the code, just think, in math, if you have a set A and a set B, how do you efficiently find if one is a subset of the other?". Eventually we ran out of time for the interview. As we wrapped up, he revealed to me the elusive answer: "Since you're checking if it's a subset, you should use the built-in isSubset() method that Java sets have". Of course, he hadn't conveyed to me at all that he was looking for a specific built-in method, so I thought there was some secret algorithm that I would have to write to make it go faster. I didn't mention that though, and instead replied that even if it were a built-in method I didn't see how it could be faster than O(n) in its implementation. He didn't have response, and just stammered something like "well it's built in and it's actually the most efficient way" and the interview ended awkwardly. Anyways, I had my doubts, so when I got home I checked.

There is no isSubset() in Java sets.

There is a containsAll(). It's implemented as a while loop that runs in O(n) time, making it no more efficient than writing your own loop.

Naturally, the company ghosted me too.

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

#378
post #160

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…

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…

Takehomes: The minute you allow for them to ask for 2-3 hours of work. That's the moment that they'll ask for 40+hours of work for free (and call it 2-3 hours).

Also they'll try to claim copyright on your work (with pay) and reject you outright.

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

#379
post #354

Earlier quoted context omitted.

I work with novel algorithms all day (I'm writing a decompiler.) The more I learn, the more I have confidence in the fact that I have absolutely no hope of inventing an algorithm that doesn't already exist; and that I shouldn't waste my time trying , when instead I could be spending that time digging through the nigh-infinite vault of potential solutions to my problem known as "the output of CS academia." Software en…

I think the point is that no one is being asked to derive a novel algorithm. It’s taken for granted that a person with enough experience will have an understanding of broad categories of algorithms and should be able to reason about the small changes to those algorithms that would be necessary for practical application.

Can you offhand write C++ code for a 2-3 Finger Tree, including the changes necessary to make it efficient in a strict language?

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

#380
post #356

Earlier quoted context omitted.

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

In a business, you are either don't hire them in the beginning or fire them in the end. Not everyone should be a software engineer (where would the users come from?). A large labor market organizes people into better jobs when they are passed over for or fired from a position.

> (where would the users come from?)

I'm an engineer and I use loads of software. I bet you do too.

Post reply on HN