4 ms·

I enjoy LC problem solving (but puzzles like Advent Of Code even more). However, I dislike the interviews that use these types of artificial problems, where the

I enjoy LC problem solving (but puzzles like Advent Of Code even more). However, I dislike the interviews that use these types of artificial problems, where the interviewer then only cares about an optimal solution no matter how ugly you wrote it. Once even had an interviewer tell me to “stop focusing on writing it nicely” because I wrote some type aliases (in Go). On the plus side, these interviews can also show you which companies you would not want to work for, as in the example I just gave :)

steve_adams_86 2y ago
I agree. Someone writing type aliases to make the code safer and easier to reason about would be a big green flag for me. It also helps me see how you’re modelling the solution. In day to day work this is much better aligned with the skills I care about. I’m currently pretty exhausted by this stuff. I need a job but some days I get interviews I almost want to turn down because I discover I’m going to get grilled with leetcode problems. I’m so tired of it.
- ChrisMarshallNY 2y ago
  The biggest issue that I have with LC interviews, is that they don’t reflect the real world. They come from a perfect world, where every problem is solved in 50 lines or less, and will not need to be maintained. I have known many folks that constantly practice these, and are extremely good at them. Many practice sites, optimize for target companies, advising on how to solve in a manner each is looking for. They also frequently optimize for recent school graduates, as these types of problems are almost exactly how software development is taught. In my case, I write code for shipping software, every single day (including weekends. Today, I am working on a backend admin tool for an app that has been shipping since the beginning of this year), and have been, for many, many years. In fact, my entire adult life, has been shipping software and hardware products. It hasn’t always been good, and it hasn’t always been successful, but it has always shipped. Just about every single day, I am faced with at least one problem, that, if I don’t solve it, will mean that I can’t ship whatever I’m working on. Often, the solution requires that I learn something new, or unlearn something that I just know is The Right Way to Do It. So I’m usually humbled, every single day. This also takes time; sometimes, quite a lot of time. I don’t really have the bandwidth to practice code that is irrelevant to solving my daily existential programming crises. Many times, learning the new techniques required to solve the issue, involves LC-style exercises, but focused on addressing a very real-world problem, so I guess I do practice. But I am aware that today’s software industry isn’t really interested in folks like me. They want armies of uniform short-timers that will make relatively small contributions to massive codebases that will outlive them. I’m not particularly interested in that kind of work. I really enjoy what I do. I enjoy it so much, that I do it for free, as no one is interested in paying folks to do it.
dilyevsky 2y ago
I interviewed a bunch and sometimes I saw folks attempting to write a perfect code snippet and it would almost always result in them not being able to finish the actual problem I wanted to see on time (which resulted in rejection). So after a few of those I started asking people to just get to the point first and then make it nice if there’s time
- deleted 2y ago
  [deleted]
- itronitron 2y ago
  like so? #include libutils { libutils.solveProblem() }
- Insanity 2y ago
  But presumably you should be testing for people actually being able to write code, and not to solve some arbitrary problem unrelated to what 99% of engineers actually do. Being able to solve the leetcode problem tells you how well they crammed for the interview , not how well they code. And I say that as someone who is on the interviewer side of the table for the past few years at $FAANG
  - dilyevsky 2y ago
    I never asked above leetcode easy/medium anyway and would explain solutions for some problems. That was enough to see who actually coded day-to-day and who did “thought leadership” or whatever
taberiand 2y ago
When I interview candidates using coding problems, I ask them to focus on finding the solution first before improving the code design, if it appears they are spending too much time up front in that area - in which case what I'm looking for is a candidate that takes the advice on board and completes the solution first and then talks about improvements; it's a red flag if they ignore my instruction and keep fiddling with the appearance of the code over solving the problem. Of course, basic type definitions are a good sign, unless it starts taking up too much time
- teaearlgraycold 2y ago
  That sounds good. I always try to solve the problem with decent code first, and often they ask what I might improve and will do a quick clean up then.
grogenaut 2y ago
I can see where you're coming from and where the interviewer is coming from. I usually say "I like where your head is at, but unfortunately we have a limited time, lets pretend you did that and go back to x"... unless of course it's going to make things easier. Like tests, aliases to hang functions on, etc. And I give credits for what the candidate starts doing.

steve_adams_86 2y ago

I agree. Someone writing type aliases to make the code safer and easier to reason about would be a big green flag for me. It also helps me see how you’re modelling the solution. In day to day work this is much better aligned with the skills I care about. I’m currently pretty exhausted by this stuff. I need a job but some days I get interviews I almost want to turn down because I discover I’m going to get grilled with leetcode problems. I’m so tired of it.

ChrisMarshallNY 2y ago
The biggest issue that I have with LC interviews, is that they don’t reflect the real world. They come from a perfect world, where every problem is solved in 50 lines or less, and will not need to be maintained. I have known many folks that constantly practice these, and are extremely good at them. Many practice sites, optimize for target companies, advising on how to solve in a manner each is looking for. They also frequently optimize for recent school graduates, as these types of problems are almost exactly how software development is taught. In my case, I write code for shipping software, every single day (including weekends. Today, I am working on a backend admin tool for an app that has been shipping since the beginning of this year), and have been, for many, many years. In fact, my entire adult life, has been shipping software and hardware products. It hasn’t always been good, and it hasn’t always been successful, but it has always shipped. Just about every single day, I am faced with at least one problem, that, if I don’t solve it, will mean that I can’t ship whatever I’m working on. Often, the solution requires that I learn something new, or unlearn something that I just know is The Right Way to Do It. So I’m usually humbled, every single day. This also takes time; sometimes, quite a lot of time. I don’t really have the bandwidth to practice code that is irrelevant to solving my daily existential programming crises. Many times, learning the new techniques required to solve the issue, involves LC-style exercises, but focused on addressing a very real-world problem, so I guess I do practice. But I am aware that today’s software industry isn’t really interested in folks like me. They want armies of uniform short-timers that will make relatively small contributions to massive codebases that will outlive them. I’m not particularly interested in that kind of work. I really enjoy what I do. I enjoy it so much, that I do it for free, as no one is interested in paying folks to do it.

dilyevsky 2y ago

I interviewed a bunch and sometimes I saw folks attempting to write a perfect code snippet and it would almost always result in them not being able to finish the actual problem I wanted to see on time (which resulted in rejection). So after a few of those I started asking people to just get to the point first and then make it nice if there’s time

deleted 2y ago
[deleted]
itronitron 2y ago
like so? #include libutils { libutils.solveProblem() }
Insanity 2y ago
But presumably you should be testing for people actually being able to write code, and not to solve some arbitrary problem unrelated to what 99% of engineers actually do. Being able to solve the leetcode problem tells you how well they crammed for the interview , not how well they code. And I say that as someone who is on the interviewer side of the table for the past few years at $FAANG
- dilyevsky 2y ago
  I never asked above leetcode easy/medium anyway and would explain solutions for some problems. That was enough to see who actually coded day-to-day and who did “thought leadership” or whatever

taberiand 2y ago

When I interview candidates using coding problems, I ask them to focus on finding the solution first before improving the code design, if it appears they are spending too much time up front in that area - in which case what I'm looking for is a candidate that takes the advice on board and completes the solution first and then talks about improvements; it's a red flag if they ignore my instruction and keep fiddling with the appearance of the code over solving the problem. Of course, basic type definitions are a good sign, unless it starts taking up too much time

teaearlgraycold 2y ago
That sounds good. I always try to solve the problem with decent code first, and often they ask what I might improve and will do a quick clean up then.

grogenaut 2y ago

I can see where you're coming from and where the interviewer is coming from. I usually say "I like where your head is at, but unfortunately we have a limited time, lets pretend you did that and go back to x"... unless of course it's going to make things easier. Like tests, aliases to hang functions on, etc. And I give credits for what the candidate starts doing.