12 ms·

Assuming that a company does not look for candidates who are naturally good at ICPC-type of questions or geniuses who can come up with amazing algorithms in a m

Assuming that a company does not look for candidates who are naturally good at ICPC-type of questions or geniuses who can come up with amazing algorithms in a matter of minutes, there is actually a different way to do coding interview: just give a high-level description of a sophisticated enough algorithm to a candidate and ask the candidate to turn that into code. I think it strikes a good balance between depth in CS and the coding abilities. This type of interview is similar to what engineers do at work too. We rarely invent new algorithms, but we do read white papers or blog entries or books to pick an algorithm to implement. There are many variations in questions too: search a tree or graph with some customized criteria, using a double buffer to implement a tree-style prefix scan, implementing an integer multiplication with unlimited digits, some streaming algorithm, tree-walking to transform one tree to another, a simplified skip list, the options are unlimited. A good candidate tends to grasp the high-level concepts quickly (and they can ask questions), and is quick to convert intuition into working code. I find that there is a strong positive correlation between the performance in work and the performance in such coding interviews.

xandrius 2y ago
I still don't get why such questions are even asked as most jobs I've ever had not even remotely touched those and I've touched quite a few industries, technologies and types of companies. To me, the value of a software engineer is to ask questions, make hypotheses and be able to iterate quickly. Balancing trees, leetcode and other algorithmic stuff on the spot sounds like bringing the dreadful education system structure to the real world. Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really.
- hintymad 2y ago
  Personally I think such questions have three values: - Future proof. Unless I work for an outsourcing company, sooner or later I will want to push the envelope, or so I hope I do. And to push the envelop, one needs good CS fundamentals (maybe there are some exceptions in some specialized field). Think about React. It's a JS framework, yet to invent it one needs to understand at least compiler and graph. - Geekiness/talent filter. The same reason that the nascent Google and Microsoft and any elite companies like Jane Street asked Putnam questions, Martin Gardner questions, ICPC questions, and clever probability puzzles. Whether it's a good idea is debatable, but at least those companies want to have such type of people and they were hugely successful. Note the word filter: people who pass the interview may not be good, but failing the interview means the candidate may not be smart or geeky enough. Again, I'm not endorsing the idea but just exploring the motivation of the interview policies. - Information density. Assuming a company does want to time box a coding interview in an hour, it will be hard to come up with realistic question without spending too much time on the context. On the other hand, it's relatively easy to come up with a data structure/algorithm question that packs enough number of abstractions and inspection points to examine one's programming skill.
  - davidw 2y ago
    > Think about React. It's a JS framework, yet to invent it one needs to understand at least compiler and graph. Are you hiring people to create new JS frameworks, or to use an existing one?
    - paulddraper 2y ago
      To use an existing one. And tools are best used when they are understood.
      - davidw 2y ago
        Hiring, like many things - including engineering - is about tradeoffs. Is someone more knowledgeable "better"? Sure. But sometimes it's about getting a specific thing done, and if you're hiring someone to improve a web thing that uses React, maybe you don't need someone who understands compilers and the kernel and how the underlying hardware works and all that. Maybe you can spend a bit less and get someone who will do a perfectly adequate job.
      - bjablonski 2y ago
        How many react developers understands compilers & graphs? I'd wager that it's way below 10%.
        mewpmewp2 2y ago
        Also why do you need knowledge on compilers and graphs to create React? Firstly, React is not compiled. Secondly the graph or tree or whichever aspect can come naturally when you come up with the idea of how it would be best to maintain JS apps. In fact most important experience should have been grinding put tons of unmaintainable JS apps to come up with something like that.
        paulddraper 2y ago
        I wouldn't argue with that.
      - 2y ago
- paulddraper 2y ago
  > I still don't get why such questions are even asked The thesis is not that these exercises are representative of work but rather predictive of performance. Sales has a similar phenomenon with sports. While there is no athleticism involved in selling, many believe history in competitive sports to be a positive predictor of sales success. --- You can reasonably argue whether leetcode accomplishes this well or poorly, but... Always remember that purpose of an interview (for an employer) is to predict performance. So you are looking for the resume screening+interview process that most accurately assesses that.
  - xandrius 2y ago
    So you're saying that someone wasting their time studying leetcode to pass a stupid game is a good indicator? I would almost believe the opposite: if you actually pass those tests with flying colours, it shows me that you believe you needed to do that to be hired, while someone who's actually experienced would never in a million years step down so low.
    - paulddraper 2y ago
      I didn't state my personal opinion above, but yes I have seen leetcode aptitude to positively correlate with day-to-day problem solving.
      - xandrius 2y ago
        If your company uses leetcode to filter out employees then you are a leetcode team with your internal levels and ranks, not at all representative of the whole population of skilled IT people.
        deleted 2y ago
        [deleted]
        josephg 2y ago
        How would you, or anyone, know if your career is representative of the field? I’m sure plenty of people spend their career never learning or using data structures and algorithms knowledge. But I suspect plenty of people spend their career using this stuff all the time. Eg people who work in databases, compilers, operating systems, video games, ai, crypto currencies, and so on.
- devbent 2y ago
  >I still don't get why such questions are even asked as most jobs I've ever had not even remotely touched those and I've touched quite a few industries, technologies and types of companies. I've had to work on tree traversal stuff multiple times in my life, anything low level GUI related will work with trees a ton. I've also had to work with hash tables directly, and with memory caching layers. I really should learn to write a proper parser, as I've had to write parsers multiple times now and they are always an ugly hack job.
  - josephg 2y ago
    Yep. In a project I’m working on at the moment (collab text editing), I’ve implemented 2 different b-trees, a skip list, 2 custom file formats and a dozen or so algorithms which do various graph traversals. I get that this is uncommon, but if you scratch beneath the surface, most software (browsers, databases, compilers, OSes) are full of this stuff. Even while I was consulting stuff like this would come up. At one company we were using a custom graphql wrapper around a CMS, and it was missing some functions we needed. The wrapper was implemented like a compiler from the cms’s data format to a set of query functions. Fixing it to do what we needed it to do was really hard and broke my brain a bit. But I did it. And I wouldn’t have been able to without understanding compilers and algorithms. You can spend your whole career walking the beaten path adding features to apps and websites, and never traversing a tree at all. There’s lots of work like that out there. But if you ever want to go deeper, you’ve gotta understand data structures and algorithms. I know not everyone is suited to it, and that’s fine. But there’s definitely a reason big tech asks about this stuff.
    - sanderjd 2y ago
      > But if you ever want to go deeper, you’ve gotta understand data structures and algorithms. I don't think this is quite right. I think it's more like: If you ever want to go deeper, you've gotta be able to recognize when the problem you're solving fits a pattern for which good data structures and/or algorithms exist, and you've gotta be able to find, understand, and apply good reference material. Solving this "knowing what you don't know" problem is the best and most important role of formal education, in my opinion. It's not as important to know a topic as it is to know that it exists, and some of the basic terminology necessary to get started researching it further.
- whstl 2y ago
  I disagree with some of this. At some of my past jobs and the current one, this kind of algorithmic knowledge was important to build features that were differentiators in the market. As much as people love to pretend, not every single possible solution is in a library. Sometimes you're the one building the library. It doesn't have to be leetcode, but candidates should at least be able to produce some code that doesn't come from the README of their favourite framework. Also, talking for 30/45 mins can be enough, but it produces false positives when you have people coaching candidates. I've had people completely acing interviews that it felt like the perfect candidate. Well, it was rehearsed. When I asked for a fizz-buzz type question they completely messed it up.
  - emseetech 2y ago
    | this kind of algorithmic knowledge was important to build features that were differentiators in the market I agree with this, but with the caveat that it's extremely rare to come up with a truly novel algorithm in a production environment. Those almost always come out of academia or R&D departments. So is it important that people remember how to implement algorithms from scratch? Or is it important that they know when to identify when an existing algorithm would be useful? For instance, if I see that something is suspiciously like a Stable Marriage Problem, do I need to remember how to implement the Gale–Shapley algorithm? Or is just the ability to recognize the problem as something that has a particular solution 90% of the way there? I would argue yes. That said, I'm not sure how to test this is an interview setting.
    - whstl 2y ago
      You don't need something "truly novel" to have a market advantage. Far from it. You just need something that is not ready made. Remember that not every algorithm is neatly package-able, or has a cool name like "Stable Marriage Problem" or "Levenshtein Distance". Also: maybe your advantage is implementing some of those in a new language. Maybe your advantage is implementing one of those in SQL! Maybe you have a tree-like or graph-like structure, and you need to do something with it without having to export into some format expected by certain packages. Knowing what to implement is important too. Also, those interviews are often testing for something even simpler than those fancy algorithms. Nobody uses Fizz Buzz or Recursive Fibonacci daily, but you might need to implement something that is beyond creating views/models/controllers in your favourite MVC framework. This is what the test is checking for: coding beyond what's on the README of your framework.
- godelski 2y ago
  > if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. This is why I've always been so confused. Why is the software engineering interview wildly different from the traditional engineering interview (seniors sit down with candidates and discuss how to solve a relevant proxy problem the team is currently undergoing (has the side benefit of making the interview process potentially fruitful if you don't go with that candidate. This can be (and sometimes is) abused though)). I mean... we all speak the same language, and that isn't standard English... right?
  - deleted 2y ago
    [deleted]
  - markwkw 2y ago
    Mechanical engineering interviews seem to do the same as software: "Engineers always ask about beam bending, stress strain curves, and conservation of work. Know the theory and any technical questions are easy." Basically an equivalent of simple algorithmic questions. Not "real" because it's impossible to share enough context of a real problem in an interview to make it practical. Short, testing principles, but most importantly basic thinking and problem solving facilities.
    - godelski 2y ago
      > Mechanical engineering interviews seem to do the same as software: I've been an engineer in the past (physics undergrad -> aerospace job -> grad school/ml). I have never seen or heard of an engineer being expected to solve math equations on a whiteboard during an interview. It is expected that you already know these things. Honestly, it is expected that you have a reference to these equations and you'll have memorized what you do most. As an example, I got a call when I was finishing my undergrad for a job from Raytheon. I was supposedly the only undergrad being interviewed but first interview was a phone interview. I got asked an optics question and I said to the interviewer "you mind if I grab my book? I have it right next to me and I bookmarked that equation thinking you might ask and I'm blanking on the coefficients (explain form of equation while opening book)". He was super cool with that and at the end of the interview said I was on his short list. I see no problem with this method. We live in the age of the internet. You shouldn't be memorizing a bunch of stuff purposefully, you should be memorizing by accident (aka through routine usage). You should know the abstractions and core concepts but the details are not worth knowing off the top of your head (obviously you should have known at some point) unless you are actively using them.
- lmm 2y ago
  > Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. OK take it as read that your posturing has succeeded and we all agree that you're a brilliant interpersonal genius and the rest of us are all useless chumps. What then? The rest of us still need to interview and make hiring recommendations. Or are you suggesting that employers should fire anyone who lacks your magical talent?
  - xandrius 2y ago
    Why would you read that? I just mean that if you put 2 experienced people talking about a topic they both know, it should be pretty easy for both (or at least the interviewer) to get a rough understanding of the level of the interviewee.
    - lmm 2y ago
      > I just mean that if you put 2 experienced people talking about a topic they both know, it should be pretty easy for both (or at least the interviewer) to get a rough understanding of the level of the interviewee. Well, in my experience it's not, at least not in a "hostile" context. Most technical people are used to assuming good faith in technical conversations, and there are some very smooth bullshitters around; it's easy to construct a verbal facade that only falls apart once you ask someone to actually code.
      - MichaelZuo 2y ago
        Anyone who can't see through the 'verbal facade' is not that good. They may be very smart, but not at a bonafide genius level.
    - baobabKoodaa 2y ago
      It's not. You will find plenty of examples in this very thread.
- dennis_jeeves2 2y ago
  > Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. Actually most of them, including the really inexperienced juniors have 'figured' you out in less that 15 minutes, or at least they have decided whether to hire you or not in 15 minutes. But they have to put on a charade of being fair. Also a 'white' older male is the least preferred even if he is smarter compared to all females and the minorities that are being interviewed as long as they are not terrible. Biases galore.
  - wanderlust123 2y ago
    Got any evidence for the following claim: “ Also a 'white' older male is the least preferred even if he is smarter compared to all females and the minorities that are being interviewed as long as they are not terrible. Biases galore.”
    - renewiltord 2y ago
      He's close. The real bias is against extremely good looking guys named Rene who are also way smarter and charismatic than everyone else. Terrible bias.
      - phlakaton 2y ago
        I dunno. "Rene" sounds a lot like "renege." Which probably means you'll sign on to a project and abandon it halfway through or something. Very sus. (I wish I could say my early interviewing rubrics were any better than this. We have come a long way as a people, we Silly Valley programmers.)
      - Aeolun 2y ago
        That kinda makes sense, unless you want Rene to be your replacement.
    - spacebanana7 2y ago
      Isn't that the definition of affirmative action? Which most companies claim to do (e.g Google [1]). Admittedly Google also claims not to discriminate on the basis of protected characteristics, which is somewhat contradictory to the definition of affirmative action as positive discrimination [2]. [1] https://www.google.com/about/careers/applications/eeo/ https://www.google.com/about/careers/applications/eeo/ [2] https://en.wikipedia.org/wiki/Affirmative_action https://en.wikipedia.org/wiki/Affirmative_action
- OJFord 2y ago
  > Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. Or it's not their call, theirs is just to work with them after.
- wasteduniverse 2y ago
  [dead]
blindriver 2y ago
Unless you have data to show that your "different way" produces better results, your idea sounds exactly the same as every other idea, which is basically garbage. Lots of people have lots of ideas on what makes a great interview question, but none of them are backed by data. LeetCode-style algo questions USED to be an indicator of intelligence as per Google's investigation, but now it's so heavily gamed that I doubt there's any signal behind it anymore. Someone needs to spend time and effort and money and actually do random controlled tests to see if people who pass a particular type of test actually make good employees. But so far no one has done this, except Google as far as I've seen. But even now, I think there's no evidence that even algorithm questions are any indicator, given what I've seen.
- godelski 2y ago
  > Unless you have data to show that your "different way" produces better results, your idea sounds exactly the same as every other idea, which is basically garbage. Do you have evidence that the standard coding interview works? (There's evidence that it doesn't) I'm with you that the claim might be too strong to say "this is the way" but that's because I'm of the (very strong) opinion that interviewing is an extremely fuzzy process and there are no clear cut metrics to measure one's abilities in a significantly meaningful way. a̶l̶l̶ ̶m̶o̶d̶e̶l̶s̶ ̶a̶r̶e̶ ̶w̶r̶o̶n̶g̶ ̶b̶u̶t̶ ̶s̶o̶m̶e̶ ̶a̶r̶e̶ ̶u̶s̶e̶f̶u̶l̶ There are useful interviewing methods but certainly not "the best" method. Trying to just mark checkboxes only leads to mediocre results. The reason we're generally okay with this is because we more often than not don't need rockstars and it doesn't make sense to put a lot of time and energy into this process when we get sufficient results through lazy methods. FWIW, a typical (non-software) engineering job really just involves high level discussions like the OP suggests but even without the implementation. It is generally about seeing how the person thinks/problem solves and looking at problems they solved in the past. It isn't resource intensive and good enough. Because truth is, you don't know what someone is like as an employee until they are an employee (and even then this is fuzzy)
  - blindriver 2y ago
    > Do you have evidence that the standard coding interview works? No, I think that they are all garbage. The only way to really hire is by having a vibe check to see if they are someone the team wants to work with, making sure that the person seems competent and has a reasonable chance of being very productive, and then hiring them quick. Give them a month and if they don't seem like a good fit, then fire them, with 2 months severance. This is the only way I've seen that will produce a great team quickly, by hiring quickly and firing quickly. This is similar to what Netflix does but they also pay top of market which not too many companies can afford, but it produces the best results.
jjtheblunt 2y ago
What is ICPC?
- pseudalopex 2y ago
  International Collegiate Programming Contest
  - jjtheblunt 2y ago
    Thanks
hintymad 2y ago
And even for Google, leetcode has become noise because people simply cram the questions. When Microsoft started to use leetcode-style interviews, there were no interview site. So, people who aced the interviews were either naturally talented or were so geeky that they devoured math and puzzle books. Unfortunately, we have lost such signals nowadays.
belmarca 2y ago
Your "solution" is just another coding interview. A typical engineer doesn't begin their day thinking "I should implement a streaming algorithm" out of nowhere (and if they do, they can always seek reference). They analyze a (typically underspecified) problem, figure out the constraints, and then start thinking about a solution. Note that both processes, analysis and solution, can take hours, days, weeks or months! Coding interviews have everything backwards by providing synthetic solutions to mostly out-of-context problems. For example, interviewers could: - Share some portion of a codebase with the candidate prior to the interview - Go over the code with the candidate That's it. You will know really fast who's senior and who's never wrote software. It can't be faked. And it can be adapted to mostly any positions (backend, frontend, devops, architecture, whatever).
YZF 2y ago
I have a different take on this. I ask a fairly simple coding question and have them write code. No fancy algorithms to memorize or competition style coding. I want to see if they can think in code. If they can translate something simple to written code. There's always a chance to have a conversation as well to probe different aspects of their understanding. A few of those by a few people and I think you get a pretty good read. Mix in some questions about their work and/or some general knowledge. I've also given people code to read (real world code) and explain to me. For Algorithms and Data Structures I can look at their grades if they're fresh out of school. But we all know most of our work is not that (someone's gonna show up on the thread and say differently - I'm sure ;) ). If you can think in code and have the right mental models implementing an algorithm from a book isn't hard if you really have to.
- tgv 2y ago
  I used that approach too for a beginning frontend dev: see if they can get a solution to straight-forward problems, and ask them to explain it afterwards. They got all the time they needed, and a clean laptop with wifi. Two candidates came out well, two others didn't. That was a bit shocking, given the low bar. But it won't cut it for a senior. Such people should be able to answer a wide range of questions, including some algorithm and data structure stuff. Not that they have to be able to code a min-max-heap from scratch, but they have to know what's out there, how to use it, and how to keep the overview of an entire project. That's not going to be evident from a coding interview. So, horses for courses.
  - YZF 2y ago
    I agree. For more senior people I'd mix in systems, architecture, design trade-offs and such. I'd want to see they have actually delivered something in their career and dig into the details.
thbb123 2y ago
My approach is to ask the candidate to show me some code they've written ( could be for class project, but one requirement for me to interview them is that they have a GitHub) and explain the choices they made or other anecdotes that surround the project.
android521 2y ago
Good idea. But the focus on algorithms is maybe overkill for at least 80% to 90% of companies. Perhaps lay out some subset of the business requirements or problems the company is working on and ask them to turn that into working code is more suitable

xandrius 2y ago

I still don't get why such questions are even asked as most jobs I've ever had not even remotely touched those and I've touched quite a few industries, technologies and types of companies. To me, the value of a software engineer is to ask questions, make hypotheses and be able to iterate quickly. Balancing trees, leetcode and other algorithmic stuff on the spot sounds like bringing the dreadful education system structure to the real world. Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really.

hintymad 2y ago
Personally I think such questions have three values: - Future proof. Unless I work for an outsourcing company, sooner or later I will want to push the envelope, or so I hope I do. And to push the envelop, one needs good CS fundamentals (maybe there are some exceptions in some specialized field). Think about React. It's a JS framework, yet to invent it one needs to understand at least compiler and graph. - Geekiness/talent filter. The same reason that the nascent Google and Microsoft and any elite companies like Jane Street asked Putnam questions, Martin Gardner questions, ICPC questions, and clever probability puzzles. Whether it's a good idea is debatable, but at least those companies want to have such type of people and they were hugely successful. Note the word filter: people who pass the interview may not be good, but failing the interview means the candidate may not be smart or geeky enough. Again, I'm not endorsing the idea but just exploring the motivation of the interview policies. - Information density. Assuming a company does want to time box a coding interview in an hour, it will be hard to come up with realistic question without spending too much time on the context. On the other hand, it's relatively easy to come up with a data structure/algorithm question that packs enough number of abstractions and inspection points to examine one's programming skill.
- davidw 2y ago
  > Think about React. It's a JS framework, yet to invent it one needs to understand at least compiler and graph. Are you hiring people to create new JS frameworks, or to use an existing one?
  - paulddraper 2y ago
    To use an existing one. And tools are best used when they are understood.
    - davidw 2y ago
      Hiring, like many things - including engineering - is about tradeoffs. Is someone more knowledgeable "better"? Sure. But sometimes it's about getting a specific thing done, and if you're hiring someone to improve a web thing that uses React, maybe you don't need someone who understands compilers and the kernel and how the underlying hardware works and all that. Maybe you can spend a bit less and get someone who will do a perfectly adequate job.
    - bjablonski 2y ago
      How many react developers understands compilers & graphs? I'd wager that it's way below 10%.
      - mewpmewp2 2y ago
        Also why do you need knowledge on compilers and graphs to create React? Firstly, React is not compiled. Secondly the graph or tree or whichever aspect can come naturally when you come up with the idea of how it would be best to maintain JS apps. In fact most important experience should have been grinding put tons of unmaintainable JS apps to come up with something like that.
      - paulddraper 2y ago
        I wouldn't argue with that.
    - 2y ago
paulddraper 2y ago
> I still don't get why such questions are even asked The thesis is not that these exercises are representative of work but rather predictive of performance. Sales has a similar phenomenon with sports. While there is no athleticism involved in selling, many believe history in competitive sports to be a positive predictor of sales success. --- You can reasonably argue whether leetcode accomplishes this well or poorly, but... Always remember that purpose of an interview (for an employer) is to predict performance. So you are looking for the resume screening+interview process that most accurately assesses that.
- xandrius 2y ago
  So you're saying that someone wasting their time studying leetcode to pass a stupid game is a good indicator? I would almost believe the opposite: if you actually pass those tests with flying colours, it shows me that you believe you needed to do that to be hired, while someone who's actually experienced would never in a million years step down so low.
  - paulddraper 2y ago
    I didn't state my personal opinion above, but yes I have seen leetcode aptitude to positively correlate with day-to-day problem solving.
    - xandrius 2y ago
      If your company uses leetcode to filter out employees then you are a leetcode team with your internal levels and ranks, not at all representative of the whole population of skilled IT people.
      - deleted 2y ago
        [deleted]
      - josephg 2y ago
        How would you, or anyone, know if your career is representative of the field? I’m sure plenty of people spend their career never learning or using data structures and algorithms knowledge. But I suspect plenty of people spend their career using this stuff all the time. Eg people who work in databases, compilers, operating systems, video games, ai, crypto currencies, and so on.
devbent 2y ago
>I still don't get why such questions are even asked as most jobs I've ever had not even remotely touched those and I've touched quite a few industries, technologies and types of companies. I've had to work on tree traversal stuff multiple times in my life, anything low level GUI related will work with trees a ton. I've also had to work with hash tables directly, and with memory caching layers. I really should learn to write a proper parser, as I've had to write parsers multiple times now and they are always an ugly hack job.
- josephg 2y ago
  Yep. In a project I’m working on at the moment (collab text editing), I’ve implemented 2 different b-trees, a skip list, 2 custom file formats and a dozen or so algorithms which do various graph traversals. I get that this is uncommon, but if you scratch beneath the surface, most software (browsers, databases, compilers, OSes) are full of this stuff. Even while I was consulting stuff like this would come up. At one company we were using a custom graphql wrapper around a CMS, and it was missing some functions we needed. The wrapper was implemented like a compiler from the cms’s data format to a set of query functions. Fixing it to do what we needed it to do was really hard and broke my brain a bit. But I did it. And I wouldn’t have been able to without understanding compilers and algorithms. You can spend your whole career walking the beaten path adding features to apps and websites, and never traversing a tree at all. There’s lots of work like that out there. But if you ever want to go deeper, you’ve gotta understand data structures and algorithms. I know not everyone is suited to it, and that’s fine. But there’s definitely a reason big tech asks about this stuff.
  - sanderjd 2y ago
    > But if you ever want to go deeper, you’ve gotta understand data structures and algorithms. I don't think this is quite right. I think it's more like: If you ever want to go deeper, you've gotta be able to recognize when the problem you're solving fits a pattern for which good data structures and/or algorithms exist, and you've gotta be able to find, understand, and apply good reference material. Solving this "knowing what you don't know" problem is the best and most important role of formal education, in my opinion. It's not as important to know a topic as it is to know that it exists, and some of the basic terminology necessary to get started researching it further.
whstl 2y ago
I disagree with some of this. At some of my past jobs and the current one, this kind of algorithmic knowledge was important to build features that were differentiators in the market. As much as people love to pretend, not every single possible solution is in a library. Sometimes you're the one building the library. It doesn't have to be leetcode, but candidates should at least be able to produce some code that doesn't come from the README of their favourite framework. Also, talking for 30/45 mins can be enough, but it produces false positives when you have people coaching candidates. I've had people completely acing interviews that it felt like the perfect candidate. Well, it was rehearsed. When I asked for a fizz-buzz type question they completely messed it up.
- emseetech 2y ago
  | this kind of algorithmic knowledge was important to build features that were differentiators in the market I agree with this, but with the caveat that it's extremely rare to come up with a truly novel algorithm in a production environment. Those almost always come out of academia or R&D departments. So is it important that people remember how to implement algorithms from scratch? Or is it important that they know when to identify when an existing algorithm would be useful? For instance, if I see that something is suspiciously like a Stable Marriage Problem, do I need to remember how to implement the Gale–Shapley algorithm? Or is just the ability to recognize the problem as something that has a particular solution 90% of the way there? I would argue yes. That said, I'm not sure how to test this is an interview setting.
  - whstl 2y ago
    You don't need something "truly novel" to have a market advantage. Far from it. You just need something that is not ready made. Remember that not every algorithm is neatly package-able, or has a cool name like "Stable Marriage Problem" or "Levenshtein Distance". Also: maybe your advantage is implementing some of those in a new language. Maybe your advantage is implementing one of those in SQL! Maybe you have a tree-like or graph-like structure, and you need to do something with it without having to export into some format expected by certain packages. Knowing what to implement is important too. Also, those interviews are often testing for something even simpler than those fancy algorithms. Nobody uses Fizz Buzz or Recursive Fibonacci daily, but you might need to implement something that is beyond creating views/models/controllers in your favourite MVC framework. This is what the test is checking for: coding beyond what's on the README of your framework.
godelski 2y ago
> if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. This is why I've always been so confused. Why is the software engineering interview wildly different from the traditional engineering interview (seniors sit down with candidates and discuss how to solve a relevant proxy problem the team is currently undergoing (has the side benefit of making the interview process potentially fruitful if you don't go with that candidate. This can be (and sometimes is) abused though)). I mean... we all speak the same language, and that isn't standard English... right?
- deleted 2y ago
  [deleted]
- markwkw 2y ago
  Mechanical engineering interviews seem to do the same as software: "Engineers always ask about beam bending, stress strain curves, and conservation of work. Know the theory and any technical questions are easy." Basically an equivalent of simple algorithmic questions. Not "real" because it's impossible to share enough context of a real problem in an interview to make it practical. Short, testing principles, but most importantly basic thinking and problem solving facilities.
  - godelski 2y ago
    > Mechanical engineering interviews seem to do the same as software: I've been an engineer in the past (physics undergrad -> aerospace job -> grad school/ml). I have never seen or heard of an engineer being expected to solve math equations on a whiteboard during an interview. It is expected that you already know these things. Honestly, it is expected that you have a reference to these equations and you'll have memorized what you do most. As an example, I got a call when I was finishing my undergrad for a job from Raytheon. I was supposedly the only undergrad being interviewed but first interview was a phone interview. I got asked an optics question and I said to the interviewer "you mind if I grab my book? I have it right next to me and I bookmarked that equation thinking you might ask and I'm blanking on the coefficients (explain form of equation while opening book)". He was super cool with that and at the end of the interview said I was on his short list. I see no problem with this method. We live in the age of the internet. You shouldn't be memorizing a bunch of stuff purposefully, you should be memorizing by accident (aka through routine usage). You should know the abstractions and core concepts but the details are not worth knowing off the top of your head (obviously you should have known at some point) unless you are actively using them.
lmm 2y ago
> Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. OK take it as read that your posturing has succeeded and we all agree that you're a brilliant interpersonal genius and the rest of us are all useless chumps. What then? The rest of us still need to interview and make hiring recommendations. Or are you suggesting that employers should fire anyone who lacks your magical talent?
- xandrius 2y ago
  Why would you read that? I just mean that if you put 2 experienced people talking about a topic they both know, it should be pretty easy for both (or at least the interviewer) to get a rough understanding of the level of the interviewee.
  - lmm 2y ago
    > I just mean that if you put 2 experienced people talking about a topic they both know, it should be pretty easy for both (or at least the interviewer) to get a rough understanding of the level of the interviewee. Well, in my experience it's not, at least not in a "hostile" context. Most technical people are used to assuming good faith in technical conversations, and there are some very smooth bullshitters around; it's easy to construct a verbal facade that only falls apart once you ask someone to actually code.
    - MichaelZuo 2y ago
      Anyone who can't see through the 'verbal facade' is not that good. They may be very smart, but not at a bonafide genius level.
  - baobabKoodaa 2y ago
    It's not. You will find plenty of examples in this very thread.
dennis_jeeves2 2y ago
> Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. Actually most of them, including the really inexperienced juniors have 'figured' you out in less that 15 minutes, or at least they have decided whether to hire you or not in 15 minutes. But they have to put on a charade of being fair. Also a 'white' older male is the least preferred even if he is smarter compared to all females and the minorities that are being interviewed as long as they are not terrible. Biases galore.
- wanderlust123 2y ago
  Got any evidence for the following claim: “ Also a 'white' older male is the least preferred even if he is smarter compared to all females and the minorities that are being interviewed as long as they are not terrible. Biases galore.”
  - renewiltord 2y ago
    He's close. The real bias is against extremely good looking guys named Rene who are also way smarter and charismatic than everyone else. Terrible bias.
    - phlakaton 2y ago
      I dunno. "Rene" sounds a lot like "renege." Which probably means you'll sign on to a project and abandon it halfway through or something. Very sus. (I wish I could say my early interviewing rubrics were any better than this. We have come a long way as a people, we Silly Valley programmers.)
    - Aeolun 2y ago
      That kinda makes sense, unless you want Rene to be your replacement.
  - spacebanana7 2y ago
    Isn't that the definition of affirmative action? Which most companies claim to do (e.g Google [1]). Admittedly Google also claims not to discriminate on the basis of protected characteristics, which is somewhat contradictory to the definition of affirmative action as positive discrimination [2]. [1] https://www.google.com/about/careers/applications/eeo/ https://www.google.com/about/careers/applications/eeo/ [2] https://en.wikipedia.org/wiki/Affirmative_action https://en.wikipedia.org/wiki/Affirmative_action
OJFord 2y ago
> Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. Or it's not their call, theirs is just to work with them after.
wasteduniverse 2y ago
[dead]

blindriver 2y ago

Unless you have data to show that your "different way" produces better results, your idea sounds exactly the same as every other idea, which is basically garbage. Lots of people have lots of ideas on what makes a great interview question, but none of them are backed by data. LeetCode-style algo questions USED to be an indicator of intelligence as per Google's investigation, but now it's so heavily gamed that I doubt there's any signal behind it anymore. Someone needs to spend time and effort and money and actually do random controlled tests to see if people who pass a particular type of test actually make good employees. But so far no one has done this, except Google as far as I've seen. But even now, I think there's no evidence that even algorithm questions are any indicator, given what I've seen.

godelski 2y ago
> Unless you have data to show that your "different way" produces better results, your idea sounds exactly the same as every other idea, which is basically garbage. Do you have evidence that the standard coding interview works? (There's evidence that it doesn't) I'm with you that the claim might be too strong to say "this is the way" but that's because I'm of the (very strong) opinion that interviewing is an extremely fuzzy process and there are no clear cut metrics to measure one's abilities in a significantly meaningful way. a̶l̶l̶ ̶m̶o̶d̶e̶l̶s̶ ̶a̶r̶e̶ ̶w̶r̶o̶n̶g̶ ̶b̶u̶t̶ ̶s̶o̶m̶e̶ ̶a̶r̶e̶ ̶u̶s̶e̶f̶u̶l̶ There are useful interviewing methods but certainly not "the best" method. Trying to just mark checkboxes only leads to mediocre results. The reason we're generally okay with this is because we more often than not don't need rockstars and it doesn't make sense to put a lot of time and energy into this process when we get sufficient results through lazy methods. FWIW, a typical (non-software) engineering job really just involves high level discussions like the OP suggests but even without the implementation. It is generally about seeing how the person thinks/problem solves and looking at problems they solved in the past. It isn't resource intensive and good enough. Because truth is, you don't know what someone is like as an employee until they are an employee (and even then this is fuzzy)
- blindriver 2y ago
  > Do you have evidence that the standard coding interview works? No, I think that they are all garbage. The only way to really hire is by having a vibe check to see if they are someone the team wants to work with, making sure that the person seems competent and has a reasonable chance of being very productive, and then hiring them quick. Give them a month and if they don't seem like a good fit, then fire them, with 2 months severance. This is the only way I've seen that will produce a great team quickly, by hiring quickly and firing quickly. This is similar to what Netflix does but they also pay top of market which not too many companies can afford, but it produces the best results.

jjtheblunt 2y ago

What is ICPC?

pseudalopex 2y ago
International Collegiate Programming Contest
- jjtheblunt 2y ago
  Thanks

hintymad 2y ago

And even for Google, leetcode has become noise because people simply cram the questions. When Microsoft started to use leetcode-style interviews, there were no interview site. So, people who aced the interviews were either naturally talented or were so geeky that they devoured math and puzzle books. Unfortunately, we have lost such signals nowadays.

belmarca 2y ago

Your "solution" is just another coding interview. A typical engineer doesn't begin their day thinking "I should implement a streaming algorithm" out of nowhere (and if they do, they can always seek reference). They analyze a (typically underspecified) problem, figure out the constraints, and then start thinking about a solution. Note that both processes, analysis and solution, can take hours, days, weeks or months! Coding interviews have everything backwards by providing synthetic solutions to mostly out-of-context problems. For example, interviewers could: - Share some portion of a codebase with the candidate prior to the interview - Go over the code with the candidate That's it. You will know really fast who's senior and who's never wrote software. It can't be faked. And it can be adapted to mostly any positions (backend, frontend, devops, architecture, whatever).

YZF 2y ago

I have a different take on this. I ask a fairly simple coding question and have them write code. No fancy algorithms to memorize or competition style coding. I want to see if they can think in code. If they can translate something simple to written code. There's always a chance to have a conversation as well to probe different aspects of their understanding. A few of those by a few people and I think you get a pretty good read. Mix in some questions about their work and/or some general knowledge. I've also given people code to read (real world code) and explain to me. For Algorithms and Data Structures I can look at their grades if they're fresh out of school. But we all know most of our work is not that (someone's gonna show up on the thread and say differently - I'm sure ;) ). If you can think in code and have the right mental models implementing an algorithm from a book isn't hard if you really have to.

tgv 2y ago
I used that approach too for a beginning frontend dev: see if they can get a solution to straight-forward problems, and ask them to explain it afterwards. They got all the time they needed, and a clean laptop with wifi. Two candidates came out well, two others didn't. That was a bit shocking, given the low bar. But it won't cut it for a senior. Such people should be able to answer a wide range of questions, including some algorithm and data structure stuff. Not that they have to be able to code a min-max-heap from scratch, but they have to know what's out there, how to use it, and how to keep the overview of an entire project. That's not going to be evident from a coding interview. So, horses for courses.
- YZF 2y ago
  I agree. For more senior people I'd mix in systems, architecture, design trade-offs and such. I'd want to see they have actually delivered something in their career and dig into the details.

thbb123 2y ago

My approach is to ask the candidate to show me some code they've written ( could be for class project, but one requirement for me to interview them is that they have a GitHub) and explain the choices they made or other anecdotes that surround the project.

android521 2y ago

Good idea. But the focus on algorithms is maybe overkill for at least 80% to 90% of companies. Perhaps lay out some subset of the business requirements or problems the company is working on and ask them to turn that into working code is more suitable