Programming in general is language and framework agnostic. Someone who can write an extensible and maintainable C++ application can most likely do the same in C#, Java, Rust etc. There's decades of best practices and knowledge around what makes good software and almost none of it is specific to a language.
Most devs use a handful of algorithms in their entire career. And any algorithm they do use was probably adapted from pseudocode on Wikipedia.
It really comes down to what do you want the developer to do? Are the things you're testing them on even relevant to the job?
I'd argue what most companies are testing through their interview process is largely irrelevant.
If it's a generic programmer, then it's perhaps a position where's there's a range of technologies, maybe a range of languages to pick up and a range of existing software to support. Well in that case you want someone who's quick to learn and eager to train themselves, not afraid to ask questions, not afraid to admit they don't understand something, etc. Whether they can write quicksort on a whiteboard is probably the stupidest thing you could interview them on.
I think the best kind of interview isn't overly technical, but rather one that prods the interviewee to think about problems. Describe a fictional system, what would they suggest to make it scaleable? What would they suggest to improve performance? What would they suggest to reduce the time between writing the code and shipping it. Do they understand what a CI/CD system is? Are their first thoughts "rewrite everything!"? Do they think about iterating software development or are they the kind to dump 200 files on someone for code review?
> Describe a fictional system, what would they suggest to make it scaleable? What would they suggest to improve performance? What would they suggest to reduce the time between writing the code and shipping it.
These questions are very senior dev focused, not so sure I'd ask a junior candidate much in this direction. But I always did a question like this when I did my share of interviewing. And the idea is basically to see if the candidate has been around the block. Have they seen the sausage being made, or do they only have academic understanding of the software engineering profession?
And being on the other side, some of the best questions I've gotten was always like "describe the weirdest problem you've encountered". Talking about unexpected shit usually leads to a fun discussion, and you can showcase your ability to problem solve.
Would you agree that interviewing in psudocode is a good idea then?
But what's the content they should be interviewed on? You say no to quicksort. How about date parsing? That shows you have to handle messy cases.
What do you want them to write if not algorithms? Maybe we have a different expectation of what "algorithm" means? The term is pretty generic, but I feel captures more of the cross language stuff.
Compare a "How does javascript handle equality?" question which falls under "trivia", vs "Implement a hash table", which isn't too hard to do for a naive solution, and demonstrates that you know how the basic data structures you work with day to day work.
>But what's the content they should be interviewed on? You say no to quicksort. How about date parsing? That shows you have to handle messy cases.
But why? The vast majority of programmers don't ever need to write code to parse a date. It's just another test completely irrelevant to the job.
>Compare a "How does javascript handle equality?" question which falls under "trivia", vs "Implement a hash table", which isn't too hard to do for a naive solution, and demonstrates that you know how the basic data structures you work with day to day work.
Both are pretty bad interview questions. Is this a Javascript position? If they don't know how it handles equality do you really think that is the end of the the world for the interviewee, does that make them a bad programmer? It's something you could explain to them during the interview in under 5 minutes (and you should, it eases the pressure on the interviewee). So really what's the worth of asking it?
Likewise, "implement a hash table". Pointless. Ask them "Do you know how a hash table works under the hood?", chances are they might not know exactly how to implement one but they do understand roughly how it works. If they don't know then describe a simple implementation and quiz them on why it's built this way, do they understand the "why" even if they don't understand the "how". Most competent programmers can implement a hash table given an explanation of how it works which is why I don't think it's a good question to ask someone during an interview. It's just a memory test, not a test of how good they are as a programmer, how good they'd fit into a team, how good they would be at designing a large system, how good they'd be at weighing up the pros and cons of different solutions.
This is why interviews should be discussions, not tests.
> vs "Implement a hash table", which isn't too hard to do for a naive solution, and demonstrates that you know how the basic data structures you work with day to day work.
I disagree, anyone can write out an algorithm from memory. That's not hard, and does not prove that you know what you're doing.
I've done my small share of interviewing, and I always did a little bit of whiteboard coding, but the objective was never to see if the candidate remembered algorithms, but to see if they could execute code in their head.
Because I've encountered "programmers" who clearly couldn't execute code in their head, and whose idea of programming was copy-pasting something and heuristically modifying it until it did what it was supposed to do, instead of knowing what the code does. And you really want to make sure you screen for this group so that they fail the interview.
Most devs use a handful of algorithms in their entire career. And any algorithm they do use was probably adapted from pseudocode on Wikipedia.
It really comes down to what do you want the developer to do? Are the things you're testing them on even relevant to the job?
I'd argue what most companies are testing through their interview process is largely irrelevant.
If it's a generic programmer, then it's perhaps a position where's there's a range of technologies, maybe a range of languages to pick up and a range of existing software to support. Well in that case you want someone who's quick to learn and eager to train themselves, not afraid to ask questions, not afraid to admit they don't understand something, etc. Whether they can write quicksort on a whiteboard is probably the stupidest thing you could interview them on.
I think the best kind of interview isn't overly technical, but rather one that prods the interviewee to think about problems. Describe a fictional system, what would they suggest to make it scaleable? What would they suggest to improve performance? What would they suggest to reduce the time between writing the code and shipping it. Do they understand what a CI/CD system is? Are their first thoughts "rewrite everything!"? Do they think about iterating software development or are they the kind to dump 200 files on someone for code review?