4 ms·

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 topi

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.
  - josephg 4y ago
    Yeah I agree 100%. A good technical interview should involve a lot of different parts. Some programming, some conversational. Essentially, there's 100 different things you need to know to do your job well. The job of a good technical interview is to give you a (biased) sample from those 100 elements of knowledge. So, some practical programming work. Some conversational - "how is this going to be deployed and maintained". Etc.

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.
- josephg 4y ago
  Yeah I agree 100%. A good technical interview should involve a lot of different parts. Some programming, some conversational. Essentially, there's 100 different things you need to know to do your job well. The job of a good technical interview is to give you a (biased) sample from those 100 elements of knowledge. So, some practical programming work. Some conversational - "how is this going to be deployed and maintained". Etc.