> Where, in any of my day-to-day job duties, am I going to need to find the kth permutation of a set of numbers?
People who don't know algorithms and data structures tend not to see them where they exist, so it becomes a subjectively self-fulfilling prophecy. You may not need to clone a graph in your day to day work, but seeing graphs where graphs exist can lead you to better solutions in a way that might seem "magical" to others. Even if it isn't too significant, that small edge can make a difference sometimes. Employers rightly want that.
No they don't. Employers heard that Google asks questions like these, and Google is worth eleventy skrillion dollars, so if we ask the questions Google asks we'll be worth eleventy skrillion dollars too!
In much the same way, last decade everybody knew Microsoft asked riddles, and Microsoft was worth more money than anyone could imagine, so obviously asking riddles is the way to end up worth more money than anyone can imagine.
It's basically this comic, but implemented in tech interviews instead of in schooling:
Meanwhile the only reason these things seem to "work" for Google et al. is that they get so many applicants they can afford to turn down huge numbers of perfectly intelligent, perfectly-qualified people who might not do so well on an algorithms pop quiz. And at the same time they've made the process easy to game: you can literally get books of Google-style interview questions, study them, and then pass tech interviews without the underlying knowledge/experience the questions are allegedly selecting for.
I just wonder which company will be the next big breakout hit and what irrelevant thing they'll do in interviews that everyone will hurry to nod their heads and sagely agree with as a great indicator of the kinds of things "employers want".
I'd like to hear how you interview candidates and what has been your success? The process could certainly be improved since we have very little time to really know the candidates.
Not parent but my current employer has an interview process that I find fairly efficient.
During the hour-and-a-half or so of interview, I was asked to do a few things:
1. explain my technical background, projects I've worked on
2. explain one project in depth, from entry-point to client
3. discuss future features of that project
4. let me implement one feature in that list while they go have some coffee
5. show off my new feature!
Even though the technology I used was not the technology they use, I think my employer wanted to see how well I communicate technically, how well I understand, and how fast I can put things together. He seemed to like the fact that I had a lot of failed iterations and Googled to get through snags.
Another interview process I was quite fond of had me working on one of _their_ pet projects; looking through their code base, identifying possible improvements/features, and implementing those improvements in a new git branch.
Of course, that process may not work with EVERY technical interview, but my bet is that practical interviews like these are more likely to show an employee's technical prowess than a person simply memorizing algorithms. While I agree that there is a place for algorithms, it should not be the focus of an interview.
We provide applicants with a small coding exercise (one they do at home) that compels them to find a good, clean and algorithmic approach to a problem, shows how they organize and understand abstract concepts, and whether or not they consider testing when writing code.
The example is a checkout register at a store.
They submit their example, and we review it, make notes, and when they come in, we go over it and talk about it. What we look for is the code itself and also how they explain their decisions along the way.
We find that this really paints a very vivid picture of the candidate, far more than white boarding exercises, stand behind them coding exercises or trivial bs questions.
From what I have heard of my friends at work actually doing interviews, they mostly focus on finding out how much does their candidate lie on their cv :)
I.e: "So you want to join our product security team and say that you know xml. How would you go about finding an exploit in an app that you can get to parse an xml file?"
And I have heard several stories from several people doing interviews, where the candidate failed this sort of question particularly badly :)
So simple questions in vein of "I see you tell us you know x, that might help you solve problem y we deal in our team often, how would you do it?"
Posting this under a throwaway so that people at my existing job do not recognize the account.
Completely agree, and you might even learn something during the interview, especially if you were previously the "API" programmer group. I'm entirely self-taught, so I will readily admit that my algorithms and data-structures knowledge is not where I feel it should be.
I did an interview somewhat recently where we talked about a problem that required the use of a data-structure that I had literally read about in preparation for said interview two days earlier, but did not really understand a solid use case for it. As we discussed the problem that was presented, I ended up arriving at the correct solution and everything was happy, but that's not the cool part. The cool part was that as a result of that conversation, all of the sudden the use for that data-structure "clicked", and an entire class of problems suddenly became obvious in how to optimally solve. I will actually be using that exact solution in a side project that's in the planning phase
I haven't done the on-site interview yet, but regardless of whether or not I get an offer (or even accept the offer if one is made), I know that I'm going to walk away from this interview a better engineer for having learned about these algorithms and data-structures just to interview.
Looking back at that phone interview, I wonder just how many other problems I've encountered and solved that would've been better served if I knew more about algorithms and data structures.
The vast majority of my CS schooling was theoretical or algorithmic, so I initially felt like I was at a disadvantage for not knowing the frameworks that everyone else used constantly.
After discussing design decisions with people though, I often feel that they think everything will be very difficult and keep hemming and hawing over concerns about how long things will take to implement. I've had to write down pseudo-code for them showing how everything can be done in a single loop and dictionary lookup or something like that to get them to actually agree to their half of the design.
I think the biggest benefit of a strong theoretical background is just knowing beforehand how easy so many problems actually are.
I will freely admit my algo knowledge isn't where it needs to be. But I know an algorithm's need where I see one, and consistently. The problems always contain a very specific problem space:
1) sorting
2) Large tables of information
3) categorizing
In nearly every case, the appropriate, well researched, proofed, Ph.D approved answer is a quick google away. If you're asking algorithm questions in your interviews, all you're looking for is someone's ability to conjure from memory an appropriate approach. Congratulations, you hired a flash card.
You know who I want to hire? Someone who shows creativity and drive through their experience (usually surfaces as having their hands in a lot of disciplines both CS and non), and someone who learns quickly. If they can implement an algorithm (not needing to conjure it on the spot), that's all I need. By the way, no self respecting algo researcher/analyst sits down for 45 minutes to come to a correct and efficient solution to an algorithm problem.
Enjoy your grad students. I'll take a maker any day.
> all you're looking for is someone's ability to conjure from memory an appropriate approach
So, it's worth mentioning that there are two types of algorithm questions.
You seem to be complaining about the "show me merge sort" style, where the interviewer picks a commonly-taught well-known algorithm. I have, in practice, seen this style exactly once (maybe I'm missing a broader trend, though) and it thus comes off as a strawman.
The other type involves solving problems that most interviewees, by shear numbers, can't possibly have seen before. Here, you're testing for on-the-spot thinking, not memorization. This is what I actually see when I interview.
Because in practice, how many people need to implement merge sort? 99% of them should call `List.sort` and be done. But the algorithm for traversing this strange dual-tree structure or whatever probably isn't in the standard library, and I do need someone who can do that.
The problem is that the problem you think the interviewee hasn't seen is derived from common problems the interviewee has seen. 99% of the time, if the interviewee has a background in programming competitions then they will sound very intelligent, and the further they move from that background the worse they'll do. You're selecting for familiarity, not creativity.
> The other type involves solving problems that most interviewees, by shear numbers, can't possibly have seen before. Here, you're testing for on-the-spot thinking, not memorization. This is what I actually see when I interview.
And why do you think this is the best way to test for on-the-spot-thinking? I know I personally need a bit of time to soak in an algorithmic question to arrive at a viable conclusion. I might have some theories or hypotheses at first, but in the context of a 45 minute interview, it's simply testing nothing other than whether or not I've been exposed to this particular problem before. I happen to be great at thinking on the spot when I need to improvise through a problem or debug a problem, but that would fail your metric because you asked the wrong question.
I know this may come as a great surprise to you, but not all questions of a person's abilities can be answered by whether or not they can write a joint scheduling implementation in the amount of time it takes to get through a short lunch.
> The other type involves solving problems that most interviewees, by shear numbers, can't possibly have seen before. Here, you're testing for on-the-spot thinking, not memorization. This is what I actually see when I interview.
I just wrote this comment on another thread here, I think it is relevant:
I don't know what your experience is, but given what other folks have shared here, it seems that those with 10+ years of experience in the industry, doing mostly "API programming," have said "I don't use this sort of knowledge day-to-day." I have nearly fifteen years in the industry. I am also entirely self-taught, and have never done any in-depth study on algorithms and data structures. There have been a few times that my lack of knowledge was limiting (and most of those times involved complex queries), but those times are few and far between.
But, you are correct: "a small edge can make a difference sometimes." To some employers that matters. To others? Maybe not so much. Maybe they are happy with a few folks that can deal with the algorithm issues, while the rest of team cranks out APIs and fixes bugs and supports old products.
People who don't know algorithms and data structures tend not to see them where they exist, so it becomes a subjectively self-fulfilling prophecy. You may not need to clone a graph in your day to day work, but seeing graphs where graphs exist can lead you to better solutions in a way that might seem "magical" to others. Even if it isn't too significant, that small edge can make a difference sometimes. Employers rightly want that.