Thank you very much for sharing your insights and experience with job interviews. As I have to do quite a few of them myself, I am always interested in what others do, what their experience is and what's the "right" thing to do.
I disagree with one of your points though, when you say that basic algorithmic skills are not important for most software developers. To me, it sounds like "my mechanic does not have to know about metals, the car manufacturer already has selected the best materials".
Even though you will most likely won't have to implement a sorting algorithm yourself today, I find it a very valuable skill for a developer to be able to judge the complexity of what they are doing. i.e. when having three nested loops and performance issues, skilled devs will try to reduce the number of iterations first and only afterwards optimize the inner part, while inexperienced devs often go for the core first ("that's where the actual computation is done). Of course, you can read this yourself quite quickly, but it needs some training to realize these things while writing code. That's why I think it's important to most devs and with debating on an interview.
Experienced software and UX guy. Over 20 years making professional software. Lots of tech/tools/languages. Father of 7. Armchair philosopher. Currently focused on full stack dev with React, Node..
Thanks. I appreciate the thoughtful response. I'll stay away from the analogy because that can lead to rabbit holes that aren't applicable.
I wouldn't argue that knowing algorithms and judging computational complexity aren't useful. My contention is that they are, in the larger scheme of things, not very important during normal development. When you consider comparatively how little time you have with a candidate, I think it's wise to optimize that time for the issues that really make a bigger impact on a day-to-day basis.
I've worked with very smart devs who know lower-level things inside and out, but that can actually work against them. These are often the same devs who pride themselves on things like brevity and cleverness of code, which tends to accumulate to difficult to maintain code. They also can tend to focus on less important details and premature optimization that inhibits forward momentum on projects.
I personally value someone who cares more about code readability and clarity, who might need to spend an extra four hours to solve the occasional performance problem, more than the algorithmic genius. Again, this is speaking of general business software development. I absolutely acknowledge that different types of dev problems/domains call for different types of skilled devs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you very much for sharing your insights and experience with job interviews. As I have to do quite a few of them myself, I am always interested in what others do, what their experience is and what's the "right" thing to do.
I disagree with one of your points though, when you say that basic algorithmic skills are not important for most software developers. To me, it sounds like "my mechanic does not have to know about metals, the car manufacturer already has selected the best materials".
Even though you will most likely won't have to implement a sorting algorithm yourself today, I find it a very valuable skill for a developer to be able to judge the complexity of what they are doing. i.e. when having three nested loops and performance issues, skilled devs will try to reduce the number of iterations first and only afterwards optimize the inner part, while inexperienced devs often go for the core first ("that's where the actual computation is done). Of course, you can read this yourself quite quickly, but it needs some training to realize these things while writing code. That's why I think it's important to most devs and with debating on an interview.
Thanks. I appreciate the thoughtful response. I'll stay away from the analogy because that can lead to rabbit holes that aren't applicable.
I wouldn't argue that knowing algorithms and judging computational complexity aren't useful. My contention is that they are, in the larger scheme of things, not very important during normal development. When you consider comparatively how little time you have with a candidate, I think it's wise to optimize that time for the issues that really make a bigger impact on a day-to-day basis.
I've worked with very smart devs who know lower-level things inside and out, but that can actually work against them. These are often the same devs who pride themselves on things like brevity and cleverness of code, which tends to accumulate to difficult to maintain code. They also can tend to focus on less important details and premature optimization that inhibits forward momentum on projects.
I personally value someone who cares more about code readability and clarity, who might need to spend an extra four hours to solve the occasional performance problem, more than the algorithmic genius. Again, this is speaking of general business software development. I absolutely acknowledge that different types of dev problems/domains call for different types of skilled devs.