3 ms·

I'm not going to defend "leetcode grinding" and its pathologies but TBF this is problematic: > "make a linked list" no, just use a library like everyone else.

by gumby 3y ago

I'm not going to defend "leetcode grinding" and its pathologies but TBF this is problematic: > "make a linked list" no, just use a library like everyone else. > "Implement addition in python but with string inputs", "no you can't use the built in x" All of that "clever" shit should be filtered out at PR/MR/diff review time. Sure, those statements (just use an existing library) are what you'll do in practice especially as a beginner. But there is value in asking these kinds of questions. One is "do you know what's going on under the hood?" On another post I just saw a comment in which someone advocated counting the number of occurrences of something in a list by filtering it and then getting the length of the result. This is almost certainly a terrible solution as it allocates memory (which has to be freed) in what can be done in a single quick pass. By asking you such a question the interviewer can learn if you have some idea of the tradeoffs and why something might be a good or bad idea. These are the kinds of decisions that can have order of magnitude impacts on runtime, which can have huge impact on the company's costs. Likewise doing arithmetic with strings as inputs would expose interesting but not super complicated questions about how arithmetic works, how you parse a numeric value out of its written representation (detest the word "conversion" for this), what are interesting bounds. If the job is really so high level that you don't have to think that there's an actual machine involved, then yes the questions aren't useful. But how many jobs are really so abstract? > We don't live in the 80s anymore. we don't need to make our own sort algorithms. No, but sometimes you have to make a choice based on the data to be operated on.

KaiserPro 3y ago
> Sure, those statements (just use an existing library) are what you'll do in practice especially as a beginner The more code you write, the more you have to maintain. Sure, of course there are times where you need to re-implement something from scratch. But those times are rare (or should be). Making something from scratch without strong justification is a strong signal, just not a positive one. Now, as you point out, "when would you write x from scratch" is a great question to ask someone. I am vary wary of people that are willing to overspend innovation tokens. But thats a design/systems/culture question, not a coding question. the signal I want from a coding test is the following: o Can they demonstrate and understanding of the programming language? o Do they create readable code? o Do they ask questions? o Do they follow the style of the programme they are modifying? o Do they say "I don't know"? o Do they push back on weird or silly requirements? all of those things make working with someone much easier. None of those questions require "implement algorithm that only exist in Computer Science courses". They can all be answered by something like: "here is a program that fetches a json document, but it breaks often, please make it more reliable" That is far more realistic, and more likely to what they'll be doing. The dirty little secret about most coding jobs is that actually, the important thing is getting something functional and stable for the business, so it can make money. Then after that its responding to feature/bug requests. As a programmer, your job is to convert business logic into computer logic. 99% of the time, this doesn't mean making artisan libraries that improve some tiny metric by 20x.
- gumby 3y ago
  > o Do they ask questions? I find I get 90% of the insight from simple questions like "write a function to shuffle a deck of cards. Don't worry about simple typos like forgetting a semicolon." You learn a lot from how they set things up (make a suit class, and a vector of card classes? Or just use the integers 1-52?) and talking about that. Do they think about the problem (and, as you say, ask a couple of "requirement" questions) before diving in? One of the best hires I remember was someone who got this problem wrong (went to a lot of work to leave the deck unshuffled). We gently asked if it did what was required. Hi smacked himself on the forehead and said, "I'm a fucking idiot" (in front of us in his interview!) and quickly corrected the bug. Great guy.
  - devoutsalsa 3y ago
    If you ask me a question that boils down to “write a card shuffling algorithm”, I’m going to do less well because I’m being taxed by the thought of “Why is this person asking me to shuffle a deck of virtual cards?” During the interview, I’d probably just google “best algorithm for shuffling deck of cards in <language>”, and I’d tell you I was looking it up. If you tasked me with shuffling cards on the job, that’s what I’d do.
    - gumby 3y ago
      You could just ask, and we'd answer "it's just a simple problem so both of us can see what it's like to work together." You'd be surprised how many people show up who don't actually know how to write a for loop. And if you didn't like the experience you wouldn't want to work for us so the interview would be a success too.
      - HeyLaughingBoy 3y ago
        > don't actually know how to write a for loop My god, yes. We had a two-part problem that we used for the "work skills" part of the interview. Part 1 boiled down to writing a two-level nested for loop that was simpler than fizzbuzz. Part 2 was using that loop to solve the rest of the problem, which was far more complex. I lost track of how many candidates spent 40 of the 50 minutes just writing that loop.
SirMaster 3y ago
> One is "do you know what's going on under the hood?" On another post I just saw a comment in which someone advocated counting the number of occurrences of something in a list by filtering it and then getting the length of the result. This is almost certainly a terrible solution as it allocates memory (which has to be freed) in what can be done in a single quick pass. By asking you such a question the interviewer can learn if you have some idea of the tradeoffs and why something might be a good or bad idea. > These are the kinds of decisions that can have order of magnitude impacts on runtime, which can have huge impact on the company's costs. Then the questions should be more like: What data structure, library, method, steps, would you use to solve this problem and why. What are the tradeoffs of your choices, etc? All of this can be answered in fairly high level pseudocode too and still show that they understand the concepts etc.
alex_lav 3y ago
> Sure, those statements (just use an existing library) are what you'll do in practice especially as a beginner. I think it's really not about "beginner" vs. "expert", but moreso about the specificity of your role. If you're tasked with making general cloud services, it's probably fine. As your role gets closer to core systems/algorithms engineering, obviously that changes. > But there is value in asking these kinds of questions. There is value knowing, but the dynamic of an interview make things like this harder to ask/harder to answer. > One is "do you know what's going on under the hood?" On another post I just saw a comment in which someone advocated counting the number of occurrences of something in a list by filtering it and then getting the length of the result. This is almost certainly a terrible solution as it allocates memory (which has to be freed) in what can be done in a single quick pass. In the real world the validity of this solution depends on its input and use. Also in the real world, especially if you're not on one of the above-mentioned specialist teams, it's usually more important to be readable and maintainable instead of just purely performance oriented. So a single pass solution that's harder to grasp at a glance becomes less desirable than multiple passes as long as your performance requirements can afford it. > By asking you such a question the interviewer can learn if you have some idea of the tradeoffs and why something might be a good or bad idea. Totally, but the issue becomes "Can you figure out an algorithm on a whiteboard", instead of the (as you've already agreed) correct path of "Can you work through tradeoffs of one implementation vs. another". I think this question could pretty easily be presented in a way that isn't a quiz and also allows the programmer to demonstrate their problemsolving ability without seeming adversarial.
EMM_386 3y ago
> One is "do you know what's going on under the hood?" Why should I need to? Let's take Microsoft's .Net sort implemtation. It will intelligently determine which is the optimized sort given the conditions it's facing. Heapsort? Mergesort? Quicksort? Radix Sort. And the most-possibility optimized versions of each. This is what data scientists do. We don't need programmers standing at whiteboards writting BubbleShort and being told it's wrong. In the real world, you call .Sort() and get on with real work. Sure, you can hand-roll your own sort for hot-path cases but that's likely been taken into account anyway!
- nottorp 3y ago
  Uh oh. You realize you just stated you actually know sorting algorithms and even know enough to be able to decide to roll your own if needed?

by gumby 3y ago

KaiserPro 3y ago

> Sure, those statements (just use an existing library) are what you'll do in practice especially as a beginner The more code you write, the more you have to maintain. Sure, of course there are times where you need to re-implement something from scratch. But those times are rare (or should be). Making something from scratch without strong justification is a strong signal, just not a positive one. Now, as you point out, "when would you write x from scratch" is a great question to ask someone. I am vary wary of people that are willing to overspend innovation tokens. But thats a design/systems/culture question, not a coding question. the signal I want from a coding test is the following: o Can they demonstrate and understanding of the programming language? o Do they create readable code? o Do they ask questions? o Do they follow the style of the programme they are modifying? o Do they say "I don't know"? o Do they push back on weird or silly requirements? all of those things make working with someone much easier. None of those questions require "implement algorithm that only exist in Computer Science courses". They can all be answered by something like: "here is a program that fetches a json document, but it breaks often, please make it more reliable" That is far more realistic, and more likely to what they'll be doing. The dirty little secret about most coding jobs is that actually, the important thing is getting something functional and stable for the business, so it can make money. Then after that its responding to feature/bug requests. As a programmer, your job is to convert business logic into computer logic. 99% of the time, this doesn't mean making artisan libraries that improve some tiny metric by 20x.

gumby 3y ago
> o Do they ask questions? I find I get 90% of the insight from simple questions like "write a function to shuffle a deck of cards. Don't worry about simple typos like forgetting a semicolon." You learn a lot from how they set things up (make a suit class, and a vector of card classes? Or just use the integers 1-52?) and talking about that. Do they think about the problem (and, as you say, ask a couple of "requirement" questions) before diving in? One of the best hires I remember was someone who got this problem wrong (went to a lot of work to leave the deck unshuffled). We gently asked if it did what was required. Hi smacked himself on the forehead and said, "I'm a fucking idiot" (in front of us in his interview!) and quickly corrected the bug. Great guy.
- devoutsalsa 3y ago
  If you ask me a question that boils down to “write a card shuffling algorithm”, I’m going to do less well because I’m being taxed by the thought of “Why is this person asking me to shuffle a deck of virtual cards?” During the interview, I’d probably just google “best algorithm for shuffling deck of cards in <language>”, and I’d tell you I was looking it up. If you tasked me with shuffling cards on the job, that’s what I’d do.
  - gumby 3y ago
    You could just ask, and we'd answer "it's just a simple problem so both of us can see what it's like to work together." You'd be surprised how many people show up who don't actually know how to write a for loop. And if you didn't like the experience you wouldn't want to work for us so the interview would be a success too.
    - HeyLaughingBoy 3y ago
      > don't actually know how to write a for loop My god, yes. We had a two-part problem that we used for the "work skills" part of the interview. Part 1 boiled down to writing a two-level nested for loop that was simpler than fizzbuzz. Part 2 was using that loop to solve the rest of the problem, which was far more complex. I lost track of how many candidates spent 40 of the 50 minutes just writing that loop.

SirMaster 3y ago

> One is "do you know what's going on under the hood?" On another post I just saw a comment in which someone advocated counting the number of occurrences of something in a list by filtering it and then getting the length of the result. This is almost certainly a terrible solution as it allocates memory (which has to be freed) in what can be done in a single quick pass. By asking you such a question the interviewer can learn if you have some idea of the tradeoffs and why something might be a good or bad idea. > These are the kinds of decisions that can have order of magnitude impacts on runtime, which can have huge impact on the company's costs. Then the questions should be more like: What data structure, library, method, steps, would you use to solve this problem and why. What are the tradeoffs of your choices, etc? All of this can be answered in fairly high level pseudocode too and still show that they understand the concepts etc.

alex_lav 3y ago

> Sure, those statements (just use an existing library) are what you'll do in practice especially as a beginner. I think it's really not about "beginner" vs. "expert", but moreso about the specificity of your role. If you're tasked with making general cloud services, it's probably fine. As your role gets closer to core systems/algorithms engineering, obviously that changes. > But there is value in asking these kinds of questions. There is value knowing, but the dynamic of an interview make things like this harder to ask/harder to answer. > One is "do you know what's going on under the hood?" On another post I just saw a comment in which someone advocated counting the number of occurrences of something in a list by filtering it and then getting the length of the result. This is almost certainly a terrible solution as it allocates memory (which has to be freed) in what can be done in a single quick pass. In the real world the validity of this solution depends on its input and use. Also in the real world, especially if you're not on one of the above-mentioned specialist teams, it's usually more important to be readable and maintainable instead of just purely performance oriented. So a single pass solution that's harder to grasp at a glance becomes less desirable than multiple passes as long as your performance requirements can afford it. > By asking you such a question the interviewer can learn if you have some idea of the tradeoffs and why something might be a good or bad idea. Totally, but the issue becomes "Can you figure out an algorithm on a whiteboard", instead of the (as you've already agreed) correct path of "Can you work through tradeoffs of one implementation vs. another". I think this question could pretty easily be presented in a way that isn't a quiz and also allows the programmer to demonstrate their problemsolving ability without seeming adversarial.

EMM_386 3y ago

> One is "do you know what's going on under the hood?" Why should I need to? Let's take Microsoft's .Net sort implemtation. It will intelligently determine which is the optimized sort given the conditions it's facing. Heapsort? Mergesort? Quicksort? Radix Sort. And the most-possibility optimized versions of each. This is what data scientists do. We don't need programmers standing at whiteboards writting BubbleShort and being told it's wrong. In the real world, you call .Sort() and get on with real work. Sure, you can hand-roll your own sort for hot-path cases but that's likely been taken into account anyway!

nottorp 3y ago
Uh oh. You realize you just stated you actually know sorting algorithms and even know enough to be able to decide to roll your own if needed?