The comments on this thread are gems. Thank you all. :)
Data structures and algorithms I actually used while working at tech companies
481–490 of 547 posts
Re: Data structures and algorithms I actually used while working at tech companies
#482Earlier quoted context omitted.
The entire concept of asking someone to write code in Google Docs is just insane to me. No one would ever do that on a job, because it's remarkably awful and difficult, and the editor will fight against you every step of the way (auto-capitalization, just to name one thing). And yet somehow interviewers think that this will give them a good picture of how you'd do work on the job. Baffling.
They're doing it so that they can see your edits live, "prooving" that you're not cheating in some way. But yes, this is asinine. Sharing your desktop through a video conferencing program and using the IDE of your choice would be far more realistic test, but Google likes to put hoops up to jump through that are smaller than your body. Why can't you contort yourself like an octopus!? Fail!
Nah, it's because this is the process for phone, not video, interviews, which are somewhat more accessible. And you need the ability to record the code at the end anyway (which docs provides and a video doesn't).
Re: Data structures and algorithms I actually used while working at tech companies
#483Earlier 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.
It's easy to memorise all those too without necessarily understanding them.
Re: Data structures and algorithms I actually used while working at tech companies
#484Earlier quoted context omitted.
Well, I probably used it last time 10 years ago and still remember it. All you need to remember is that you sort points by angle from a fixed point on the convex hull, and you can easily work out the rest of the algorithm as well as the proof of correctness. Not knowing it is a relevant signal that you did not seriously attempt to compete in computer science competitions during high school and college and did not oth…
> Whether it's in Google's interest to select for that of course is debatable. I'd argue it does not. Computational geometry is a niche. It's not even a niche that's particularly relevant to most of Google's development operations. In modern software development, knowing the detail of specific algorithms off the top of your head and being able to implement them unaided is, at best, a parlor trick. I doubt very much t…
The idea is that you might need to invent a new algorithm where a technique from an existing algorithm is used in a modified way or in a new setting, and then knowing the actual technique can be essential to find an inspiration.
E.g. if you know that convex hulls can be computed by sorting by angle and sweeping, then you might come up with the idea of sorting by angle and sweeping in problems that are unrelated to convex hulls (e.g. determining what is visible from a given point in an environment with obstacles).
In general, if you know a lot of those techniques and heuristics, you will be much more effective at problem solving in domains where these techniques apply.
It is relatively rare for this to be a big factor in routine software development, so that's probably something one should filter for only if interviewing for roles where you might need to design novel algorithms (which Google probably has more than the average company).
Re: Data structures and algorithms I actually used while working at tech companies
#485Earlier quoted context omitted.
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 a…
> 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?
I'm curious what makes you think we are relaxing barriers to entry? The senior engineers I've hired are highly productive. And diverse. My process does not have a low barrier to entry. The goal is to use more accurate signals. Instead of hiring people who are good at talking about algorithms at a white board I want to hire good software engineers.
> some people fail / lose
This comes off as a condescending way of thinking about the hiring process. Even if the candidate is not qualified for the position I want to leave them feeling like I helped them a little in their career or at the very least in their interviewing skills and confidence. You can find a good fit for a role without leaving the other candidates feeling like they failed. And I think that starts to get to the crux of the problem at some companies : the process is meant to boost the ego of the interviewer. Almost every senior dev has a few stories about how the interviewer just wanted to feel superior. We can do far better than that.
Re: Data structures and algorithms I actually used while working at tech companies
#486Earlier 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…
> Design a system that ensures that doesn't happen
Well, if we live in a world with magic, I would just use the magic material to make a machine that removes the water magically.
Re: Data structures and algorithms I actually used while working at tech companies
#487As an engineer who works on security software, here's what I've empirically used on the job: 1. Tree/graph traversal (certificate validation and a couple other random places) 2. Using, not implementing, hash tables 3. Generators/iterators/streams: minimizing the number of unnecessary list traversals or allocations made when you have to shovel data around 4. Circular buffers: specifically in low latency, high throughp…
We often see the "don't roll your own crypto", and of course, in a production setting that's obligatory advice. I think that it's a valuable exercise for anyone to implement some of the algorithms and protocols, just to understand the complexity within. I did that for a minimal TLS1.2 implementation, just because, and it was a valuable exercise. Do you see any value in changing the slant you put on "don't try this at home"?
Re: Data structures and algorithms I actually used while working at tech companies
#488Earlier quoted context omitted.
Take homes are usually very time consuming.
This varies a lot. I had a take-home for a data engineer role which just asked to get and parse an xml and post a cleaned, limited json of the data. Took ~1hr. Perfect for an initial threshold.
That's fair. Usually they involve writing some sort of miniature application. Setup of the project will usually be in the range of an hour.
Re: Data structures and algorithms I actually used while working at tech companies
#489Earlier 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…
The GP isn't asking a very good question to identify that skill, is the point. Interviews in other technical industries don't ask these kinds of questions, because they're not really useful as a gauge of, well, anything useful.
Re: Data structures and algorithms I actually used while working at tech companies
#490Earlier quoted context omitted.
Seems reminiscent of the tales of early 2000s Google interviews, of the "estimate how many golf balls fit in an airplane" variety. I'm not convinced this offers a useful selection criteria other than boosting your unconscious bias on who "seems smart", but on the other hand I'm also not convinced it's any worse than the standard modern Leetcode interview.
Funnily that old style of question is far closer to my day-to-day as an engineer than a leetcode algorithms question. Most of my job involves figuring out solutions to fuzzy problems based on unknown constraints, undiscovered requirements, and often unclear end-goals. "How would you fill this airplane with golf balls?" is a fantastic question. If the candidate doesn't reply with "Why? What are you really trying to ac…
Why? Isn't the better question "how would you solve "?
I hire people to track objects via computer vision. I ask them "hey, here's a system I want, what approaches would you take", and explain that this is a 3 year research project, of course they will be giving simplistic and wrong answers and there is knowledge asymmetry here, but I'll inform you as you go as to what works and not. "Optical flow". Okay, why? What's the general algorithm? Okay, so it turns out it doesn't work in our situation because X,Y,Z. Any ideas on what you'd look at next. And so on. Because that is exactly how my day-to-day conversations and work goes. Bounce ideas off of co-workers, latch onto something that seems promising, explore, maybe it works, maybe it fails. If it fails, what does that tell you about what to try next. Along the way you can have them code a tiny piece of something they mentioned if you want to see some code. But basically you are seeing if they understand the domain you are working in (which is not golf balls on airplanes), if they have some (not comprehensive) knowledge of the domain, and if they understand book solutions don't necessarily deal with the messiness of the real world and can adapt approaches to appropriately (i.e. a 20sec/frame algorithm is not going to cut it when I need 180fps).
It bothers me that this is still somewhat unfair due to the vast information asymmetry, but I try to deal with that. And my own biases can creep in. Are they mostly using 1980s style image processing techniques? Do they understand Bayes? Do they throw ML at problems that aren't tractable that way? It's unlikely that their past experience & preferences reflect exactly what we need. What is important - can they adapt, or even better, communicate why my choices are wrong and theirs are right (I don't need a robot to grind out code reflecting my ideas, I need them to figure things out and solve things in a fairly scientific manner).
So those are the questions I try to ask. I have no evidence that I get it right, but I haven't been disappointed with the hires.