5 ms·

The best coding interviews for 90% of tech jobs are ones that are heavy on coding and light on theory. Very few jobs are particularly well served by somebody wi

The best coding interviews for 90% of tech jobs are ones that are heavy on coding and light on theory. Very few jobs are particularly well served by somebody with strong theoretical foundations, while most are well served by somebody who can pump out high quality code quickly. Yet most companies interview as if they are inventing novel storage/processing mechanisms. Theory is important to understand which tools to leverage when, of course, but not to the extent that it's typically prioritized in the typical interview. I've had plenty of people crush the theory portion of the interview and be poor performers on the job (slow coding, low volume output), but I've never had somebody crush the coding portion (implement very fast and proficiently), and perform poorly on the job

Patrol8394 4y ago
> slow coding What does that even mean?
- adam_arthur 4y ago
  You have a task to implement a new product feature and it takes you 1 week instead of 1 day. In an interview context, I've seen cases where somebody fully understands the logic underlying the solution, yet it takes them 30m to write it, while another person can do it in 5m or less. Essentially how long it takes to translate from mental understanding to working code
  - wiseowise 4y ago
    > Essentially how long it takes to translate from mental understanding to working cod Congrats, you just invented whiteboard interview.
    - adam_arthur 4y ago
      Whiteboard interview has nothing to do with coding proficiency. Writing pseudo code of an algorithm by hand does not tell you much at all about how proficient somebody is as a coder. Coding is the act of writing code, not ideating an algorithmic solution. Its almost completely orthogonal to computer science problem solving. The principles of high quality code (from a design perspective) are also completely orthogonal to runtime complexity of an algorithm.
xkqd 4y ago
Not for nothing but we have plenty of slow coders that are “low volume” but some of the most diligent and edge case counting engineer’s I’ve ever met. Even then, if the business doesn’t depend on everyone working like a banshee, my team may as well take their time. Even as their manager it’s not my job to lead a death march.
- adam_arthur 4y ago
  Most growth companies have an endless bucket of work. Somebody who produces 2x at same quality of work is worth 2x the other person, fairly objectively. It's common to find people who produce up to 10x the average. Anyone in a startup or growth oriented company is smart to optimize for these people. The most proficient and fast coders often write higher quality code too, in my experience. People who over index on comp sci theory often are lacking in theory underlying good code. But it's not mutually exclusive. Just that if you have to optimize for one, coding proficiency matters much more for startup or growth type companies. Exception might be like an AI/ML based startup with a lot of theoretical challenges. Most companies much more business/rule oriented though
  - fiddlerwoaroof 4y ago
    I think the ideal is to have both in some proportion: like 10% slow coders dedicated to maintaining the structure of the application. And 90% people who can churn out features quickly
    - ta988 4y ago
      I agree but I would say: The ratio varies depending on the kind of product and especially on where you want to be on the spectrum of speed, security, safety, time to client...
  - vorpalhex 4y ago
    How do you actually measure 2x or 10x workload while keeping quality the same? It's _very_ easy to measure how fast it takes a ticket to go from "in progress" to "done" but measuring whether code has bugs, or leads to downtime or is just impossible to parse is a different problem. If you never need code to be readable or documented I can write it quite quickly. If you want something other humans can have a hope of maintaining, that might take a bit.
RavingGoat 4y ago
I've found that coding interviews just prove that you can write rushed, crappy code to solve a problem.
- colinmhayes 4y ago
  I mean that's what we do, right?
- em-bee 4y ago
  some people can't even do that.
- wiseowise 4y ago
  > Crappy code Being able to come up with an algorithm in a reasonable time doesn’t make it crappy. No wonder you can’t pass those.
jussij 4y ago
> I've had plenty of people crush the theory portion of the interview and be poor performers on the job (slow coding, low volume output) I think the reason for that observation relates to why these interview tests are generally a waste of time. Based on the tests that I've seen, they are 'recall lots of useless information' tests. That means it's actually possible to study for these interview tests (if you have the desire) and if you can ace the test by just spending time memorizing answers. However, 'slow coding' has very little to do with coding and everything to do with problem solving. You only learn how to problem solve through lived experience and many people never learn that skill. These interview tests generally fail only because they're not actually testing for the skills needed to do the job.
- ta988 4y ago
  Anything that anyone can find in a couple of seconds on a search engine is probably not worth an interview question. And that's valid for the interviewer as well don't ask something that you could find by looking at the resume.
weatherlite 4y ago
This. I don't get why it's so hard to create this type of interviews...

Patrol8394 4y ago

> slow coding What does that even mean?

adam_arthur 4y ago
You have a task to implement a new product feature and it takes you 1 week instead of 1 day. In an interview context, I've seen cases where somebody fully understands the logic underlying the solution, yet it takes them 30m to write it, while another person can do it in 5m or less. Essentially how long it takes to translate from mental understanding to working code
- wiseowise 4y ago
  > Essentially how long it takes to translate from mental understanding to working cod Congrats, you just invented whiteboard interview.
  - adam_arthur 4y ago
    Whiteboard interview has nothing to do with coding proficiency. Writing pseudo code of an algorithm by hand does not tell you much at all about how proficient somebody is as a coder. Coding is the act of writing code, not ideating an algorithmic solution. Its almost completely orthogonal to computer science problem solving. The principles of high quality code (from a design perspective) are also completely orthogonal to runtime complexity of an algorithm.

xkqd 4y ago

Not for nothing but we have plenty of slow coders that are “low volume” but some of the most diligent and edge case counting engineer’s I’ve ever met. Even then, if the business doesn’t depend on everyone working like a banshee, my team may as well take their time. Even as their manager it’s not my job to lead a death march.

adam_arthur 4y ago
Most growth companies have an endless bucket of work. Somebody who produces 2x at same quality of work is worth 2x the other person, fairly objectively. It's common to find people who produce up to 10x the average. Anyone in a startup or growth oriented company is smart to optimize for these people. The most proficient and fast coders often write higher quality code too, in my experience. People who over index on comp sci theory often are lacking in theory underlying good code. But it's not mutually exclusive. Just that if you have to optimize for one, coding proficiency matters much more for startup or growth type companies. Exception might be like an AI/ML based startup with a lot of theoretical challenges. Most companies much more business/rule oriented though
- fiddlerwoaroof 4y ago
  I think the ideal is to have both in some proportion: like 10% slow coders dedicated to maintaining the structure of the application. And 90% people who can churn out features quickly
  - ta988 4y ago
    I agree but I would say: The ratio varies depending on the kind of product and especially on where you want to be on the spectrum of speed, security, safety, time to client...
- vorpalhex 4y ago
  How do you actually measure 2x or 10x workload while keeping quality the same? It's _very_ easy to measure how fast it takes a ticket to go from "in progress" to "done" but measuring whether code has bugs, or leads to downtime or is just impossible to parse is a different problem. If you never need code to be readable or documented I can write it quite quickly. If you want something other humans can have a hope of maintaining, that might take a bit.

RavingGoat 4y ago

I've found that coding interviews just prove that you can write rushed, crappy code to solve a problem.

colinmhayes 4y ago
I mean that's what we do, right?
em-bee 4y ago
some people can't even do that.
wiseowise 4y ago
> Crappy code Being able to come up with an algorithm in a reasonable time doesn’t make it crappy. No wonder you can’t pass those.

jussij 4y ago

> I've had plenty of people crush the theory portion of the interview and be poor performers on the job (slow coding, low volume output) I think the reason for that observation relates to why these interview tests are generally a waste of time. Based on the tests that I've seen, they are 'recall lots of useless information' tests. That means it's actually possible to study for these interview tests (if you have the desire) and if you can ace the test by just spending time memorizing answers. However, 'slow coding' has very little to do with coding and everything to do with problem solving. You only learn how to problem solve through lived experience and many people never learn that skill. These interview tests generally fail only because they're not actually testing for the skills needed to do the job.

ta988 4y ago
Anything that anyone can find in a couple of seconds on a search engine is probably not worth an interview question. And that's valid for the interviewer as well don't ask something that you could find by looking at the resume.

weatherlite 4y ago

This. I don't get why it's so hard to create this type of interviews...