4 ms·

We may think coding challenges are easy - but after interviewing many "senior" engineers I've found that it's very helpful to have _some_ sort of coding as part

We may think coding challenges are easy - but after interviewing many "senior" engineers I've found that it's very helpful to have _some_ sort of coding as part of the interview. Algorithm and Data Structures based questions are not really popular, but they are at least a known quantity and can be studied for as a candidate. I prefer more realistic scenario type coding interviews (ie implement a new feature, fix a buggy function, etc), but in any case it is impossible to actually verify what a candidate actually coded in their previous jobs.

andrew_ 4y ago
imo falling back on those kinds of code challenges indicate a lack of imagination and creativity on the part of the hiring personnel. the industry has grown so much and there are so many new tools available, people work in so many new and creative ways, that there's no reason to use methods that predate when most candidates these days were born.
- josephg 4y ago
  I don’t agree at all. If it’s so cut and dry for you, what other forms of assessment would you recommend instead? I think technical assessment needs to assess lots of skills, but obviously one of the skills to test is how good someone is at programming. There’s a few ways to do that - my personal favourite is to have a few hundred lines of buggy code with failing tests and ask the candidate to debug it for you. But from the data I’ve seen, asking someone to code something from scratch also provides a lot of signal even if you also get them to debug something. (If you were going to pick one test, coding from scratch is a better assessment for juniors and debugging is better to assess seniors). But I think some form of practical programming assessment is necessary. You won’t learn if someone can program well by talking to them. And take home programming tasks are too easily gamed. I do think you should make the programming challenge relevant to the job though. If you’re hiring a frontend dev, get them to make a webpage. A backend dev? Get them to make a set of rest endpoints wrapping a simple database. Algorithm challenges make sense for systems programming, or when you’re hiring generalists at FAANG and such. (Source: I’ve interviewed over 400 people and worked with data scientists who looked at the per question results.)
jokethrowaway 4y ago
I don't see how expecting candidates to know algorithms by heart or solving complex algorithms is useful. Whenever I encounter that at work I research the topic extensively and learn or re-learn whatever it is I need. I completely agree on testing on real tasks, given some candidates who perform terribly on those manage to squeeze by (even thanks to them passing leetcode bs interview without having real world experience).
- josephg 4y ago
  I think I broadly agree for most programming jobs. Algorithm problems are based on the philosophy that if you can implement a binary tree in 20 minutes, you’re smart enough to figure out just about anything else that comes up. They were popularised by Google, who hire with the goal of never hiring incompetent people even if it means missing out on some good people. There’s two problems with algorithm problem interviews: 1. All the people who do great at this stuff can make $300k+ at cashed up companies. There are not many people like this who want to work for you. 2. There are plenty of people who will do a great job fixing issues and adding feature to your web app who don’t know what a B-Tree is. You probably still want to hire them. So yeah, I agree generally with the advice. Most programming problems given in interviews should be relevant to the actual job on the ground.
  - intelVISA 4y ago
    I think raw DSA has its place but shouldn't be 100% LC style: too isolated and abstract. You can probably learn more by wrapping it as a tiny 'project' note: not a take home -- just a DSA/LC style 'problem' diguised inside a git repo. I'd rather see 2Sum with a Cargo.toml in a repo, seeing them scaffold this in the lang of their choice, or within an existing codebase. Justifying the full end-to-end "how is this going to be deployed and maintained", "how would you test X" is a bit more informative than "please repeat Djikstra's algorithm into the void". Of course, being good @ LC in isolation is still a proxy for (math) intelligence perhaps unpopular - but in SWE being smart isn't enough, you gotta grift, ship or hustle your way through; thinking is mostly optional.
    - 4y ago

andrew_ 4y ago

imo falling back on those kinds of code challenges indicate a lack of imagination and creativity on the part of the hiring personnel. the industry has grown so much and there are so many new tools available, people work in so many new and creative ways, that there's no reason to use methods that predate when most candidates these days were born.

josephg 4y ago
I don’t agree at all. If it’s so cut and dry for you, what other forms of assessment would you recommend instead? I think technical assessment needs to assess lots of skills, but obviously one of the skills to test is how good someone is at programming. There’s a few ways to do that - my personal favourite is to have a few hundred lines of buggy code with failing tests and ask the candidate to debug it for you. But from the data I’ve seen, asking someone to code something from scratch also provides a lot of signal even if you also get them to debug something. (If you were going to pick one test, coding from scratch is a better assessment for juniors and debugging is better to assess seniors). But I think some form of practical programming assessment is necessary. You won’t learn if someone can program well by talking to them. And take home programming tasks are too easily gamed. I do think you should make the programming challenge relevant to the job though. If you’re hiring a frontend dev, get them to make a webpage. A backend dev? Get them to make a set of rest endpoints wrapping a simple database. Algorithm challenges make sense for systems programming, or when you’re hiring generalists at FAANG and such. (Source: I’ve interviewed over 400 people and worked with data scientists who looked at the per question results.)

jokethrowaway 4y ago

I don't see how expecting candidates to know algorithms by heart or solving complex algorithms is useful. Whenever I encounter that at work I research the topic extensively and learn or re-learn whatever it is I need. I completely agree on testing on real tasks, given some candidates who perform terribly on those manage to squeeze by (even thanks to them passing leetcode bs interview without having real world experience).

josephg 4y ago
I think I broadly agree for most programming jobs. Algorithm problems are based on the philosophy that if you can implement a binary tree in 20 minutes, you’re smart enough to figure out just about anything else that comes up. They were popularised by Google, who hire with the goal of never hiring incompetent people even if it means missing out on some good people. There’s two problems with algorithm problem interviews: 1. All the people who do great at this stuff can make $300k+ at cashed up companies. There are not many people like this who want to work for you. 2. There are plenty of people who will do a great job fixing issues and adding feature to your web app who don’t know what a B-Tree is. You probably still want to hire them. So yeah, I agree generally with the advice. Most programming problems given in interviews should be relevant to the actual job on the ground.
- intelVISA 4y ago
  I think raw DSA has its place but shouldn't be 100% LC style: too isolated and abstract. You can probably learn more by wrapping it as a tiny 'project' note: not a take home -- just a DSA/LC style 'problem' diguised inside a git repo. I'd rather see 2Sum with a Cargo.toml in a repo, seeing them scaffold this in the lang of their choice, or within an existing codebase. Justifying the full end-to-end "how is this going to be deployed and maintained", "how would you test X" is a bit more informative than "please repeat Djikstra's algorithm into the void". Of course, being good @ LC in isolation is still a proxy for (math) intelligence perhaps unpopular - but in SWE being smart isn't enough, you gotta grift, ship or hustle your way through; thinking is mostly optional.
  - 4y ago