3 ms·

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

> 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.
    - neon_electro 3y ago
      Come up with better problems, please.
      - gumby 3y ago
        What would you recommend?
    - deckard1 3y ago
      you don't actually believe that "work together" crap do you? You realize you're dangling a job over their head, right? There is a power imbalance. You'll never see "work together" in an interview because you're not colleagues on equal footing.
gumby 3y ago
> 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. It really depends on what you're working on. A package to manage a dentist's office should be as off the shelf as possible. I don't care about I/O and try to do as little as possible, using whatever's off the shelf, but my HFT buddies are bumming the hell out of it, customizing the kernel, and whatnot. You may use elastic search to save you time and money, but the folks working on it have probably run over it so much there's nothing but custom code left. It's all context.
- josephg 3y ago
  Yep I absolutely agree with this. I’ve spent about the last year optimising text CRDTs so they’re actually usable in practice. A few years ago, 800mb of ram usage and 5 minutes processing was common to open a document. Now we’re talking 2mb of ram and 20ms. That is the difference between something not being viable and something being usable everywhere. And yes: my code involved a lot of custom data structures and algorithms. There were no libraries in cargo which did exactly what I needed. This thread is full of people bemoaning “leetcode problems” for being irrelevant in software jobs. But I use them all the time in my work. Software engineering is far more varied than any of our individual careers.
  - neon_electro 3y ago
    I'm happy for you that you've found a job where the things Leetcode emphasizes has merit and importance and value in your day to day work. Everyone who's on the other side of the Leetcode debate from you wants the exact same thing - an interview process that is representative of the actual day-to-day work. As a Web developer, inverting a binary tree is not a thing an employer has ever asked me to do.
    - josephg 3y ago
      Yes. You, me and the GP commenter seem to all be vigorously agreeing with one another. Job interviews should be based on what the role entails. If that includes data structures and algorithms, so be it. If not, leave them out! As the GP commenter said: > It really depends on what you're working on. ... It's all context. I brought it up because many (most) commenters in this thread seem to be claiming that this knowledge and skill is never useful. That its ridiculous to ask about this stuff in any job interviews, except as a ritualistic hazing ritual. This is also absurd. > As a Web developer, inverting a binary tree is not a thing an employer has ever asked me to do. I've never had an employer name any data structures explicitly. Its our job as the software experts to know which tools and technologies are relevant. But with that said, I can't remember ever using custom data structures in frontend website code either. If I were hiring a web developer, there are so many things I'd rather spend time talking about in an interview. (HTML & CSS knowledge, web frameworks, design skills, raw programming skill, etc.)

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.
  - neon_electro 3y ago
    Come up with better problems, please.
    - gumby 3y ago
      What would you recommend?
  - deckard1 3y ago
    you don't actually believe that "work together" crap do you? You realize you're dangling a job over their head, right? There is a power imbalance. You'll never see "work together" in an interview because you're not colleagues on equal footing.

gumby 3y ago

> 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. It really depends on what you're working on. A package to manage a dentist's office should be as off the shelf as possible. I don't care about I/O and try to do as little as possible, using whatever's off the shelf, but my HFT buddies are bumming the hell out of it, customizing the kernel, and whatnot. You may use elastic search to save you time and money, but the folks working on it have probably run over it so much there's nothing but custom code left. It's all context.

josephg 3y ago
Yep I absolutely agree with this. I’ve spent about the last year optimising text CRDTs so they’re actually usable in practice. A few years ago, 800mb of ram usage and 5 minutes processing was common to open a document. Now we’re talking 2mb of ram and 20ms. That is the difference between something not being viable and something being usable everywhere. And yes: my code involved a lot of custom data structures and algorithms. There were no libraries in cargo which did exactly what I needed. This thread is full of people bemoaning “leetcode problems” for being irrelevant in software jobs. But I use them all the time in my work. Software engineering is far more varied than any of our individual careers.
- neon_electro 3y ago
  I'm happy for you that you've found a job where the things Leetcode emphasizes has merit and importance and value in your day to day work. Everyone who's on the other side of the Leetcode debate from you wants the exact same thing - an interview process that is representative of the actual day-to-day work. As a Web developer, inverting a binary tree is not a thing an employer has ever asked me to do.
  - josephg 3y ago
    Yes. You, me and the GP commenter seem to all be vigorously agreeing with one another. Job interviews should be based on what the role entails. If that includes data structures and algorithms, so be it. If not, leave them out! As the GP commenter said: > It really depends on what you're working on. ... It's all context. I brought it up because many (most) commenters in this thread seem to be claiming that this knowledge and skill is never useful. That its ridiculous to ask about this stuff in any job interviews, except as a ritualistic hazing ritual. This is also absurd. > As a Web developer, inverting a binary tree is not a thing an employer has ever asked me to do. I've never had an employer name any data structures explicitly. Its our job as the software experts to know which tools and technologies are relevant. But with that said, I can't remember ever using custom data structures in frontend website code either. If I were hiring a web developer, there are so many things I'd rather spend time talking about in an interview. (HTML & CSS knowledge, web frameworks, design skills, raw programming skill, etc.)