4 ms·

>because leetcode/algorithmic interview questions are so fundamentally different to what we actually do day-to-day as developers. I mean, maybe hard or esoteri

>because leetcode/algorithmic interview questions are so fundamentally different to what we actually do day-to-day as developers. I mean, maybe hard or esoteric easy questions but I don't think that's true for basic things like 'find the first duplicate' or '-traverse- this graph'. When people rail on whiteboard coding, I think they mean obscure algorithmic questions and not fundamental data structure questions. I don't expect someone to be able to do Dijkstra's algorithm (or even spell Dijkstra, did I do it right?) but everyone should be comfortable enough with a bit of help doing BFS or working with linked lists, hashmaps, no? Am I crazy here?

cole-k 6y ago
I don't think you're crazy, but if their work and your work are detached enough from BFS and linked lists, why use them as the assessment criteria? It's not really that difficult to make quotidian software engineering tasks into interview questions. I've at least seen it done successfully before. More anecdotes: a nontrivial number of the "algorithmic trick" interviews I've done were questions I knew the answer to beforehand – and often the interviewer didn't care when I told them ("I just want to see how you think" or "Just show me how you'd code it" or sometimes even "OK, just tell me the solution and we'll move on to the next part"). What happens to the people who don't have the same background? Are they really less competent software engineers because their algs class didn't cover making a queue from two stacks?
BeetleB 6y ago
I've worked both as an electrical engineer, and as a SW engineer/developer. "Find the first duplicate": In my actual SW roles, this was trivial: Use a hash/map/dictionary/set. However, this isn't a typical Leetcode question - often it will be with additional constraints (cannot use a set, need O(1) space, etc). I don't doubt there are domains where this is important, but I've never had to do this in my professional work. "Traverse this graph": Probably had to do it a few times. Less than once a year. BFS: Never for my job. Linked lists: Never for my job. Yes, it is good to know what a linked list is and know if your library's data structure is using one, but again: That's not your typical Leetcode question. You'll be expected to write a linked list to solve some problem. I do get what you're saying: Stuff like linked lists and BFS are fundamental, even if most SW jobs almost never require them. It would be a red flag if a candidate didn't know the basics about them. It's another thing to ask them to code it on the fly. Going back to my electrical engineering experience: We have to take and use a ton of calculus to get the degree - much more than a CS grad will take algorithms. Yet it's a common trope that most electrical engineers will never use calculus on the job (literally not hard to find one who had a whole career in EE without using calculus). If you're doing research or are at the forefront of a discipline - sure, you'll need calculus. Or if you're doing electromagnetics, etc. The theory is built on calculus, but you don't need to know it to apply the results of the theory. Would it be a red flag if a candidate clearly didn't understand the basics of differentiation (i.e. rate of change) and integrals (i.e. summing quantities)? Perhaps. But should I ask someone to do a tricky integral for an EE role that will not require the person to do any calculus? I would be criticized by my peers, and if I kept doing that I would be excluded from interviewing. In fact, even if I ask them to do non-tricky integrals I would be criticized. Asking people to figure out a trick to solve a linked list problem is equivalent to asking EE candidates to do tricky integrals or differential equations.
- t_serpico 6y ago
  thats a great analogy

cole-k 6y ago

I don't think you're crazy, but if their work and your work are detached enough from BFS and linked lists, why use them as the assessment criteria? It's not really that difficult to make quotidian software engineering tasks into interview questions. I've at least seen it done successfully before. More anecdotes: a nontrivial number of the "algorithmic trick" interviews I've done were questions I knew the answer to beforehand – and often the interviewer didn't care when I told them ("I just want to see how you think" or "Just show me how you'd code it" or sometimes even "OK, just tell me the solution and we'll move on to the next part"). What happens to the people who don't have the same background? Are they really less competent software engineers because their algs class didn't cover making a queue from two stacks?

BeetleB 6y ago

I've worked both as an electrical engineer, and as a SW engineer/developer. "Find the first duplicate": In my actual SW roles, this was trivial: Use a hash/map/dictionary/set. However, this isn't a typical Leetcode question - often it will be with additional constraints (cannot use a set, need O(1) space, etc). I don't doubt there are domains where this is important, but I've never had to do this in my professional work. "Traverse this graph": Probably had to do it a few times. Less than once a year. BFS: Never for my job. Linked lists: Never for my job. Yes, it is good to know what a linked list is and know if your library's data structure is using one, but again: That's not your typical Leetcode question. You'll be expected to write a linked list to solve some problem. I do get what you're saying: Stuff like linked lists and BFS are fundamental, even if most SW jobs almost never require them. It would be a red flag if a candidate didn't know the basics about them. It's another thing to ask them to code it on the fly. Going back to my electrical engineering experience: We have to take and use a ton of calculus to get the degree - much more than a CS grad will take algorithms. Yet it's a common trope that most electrical engineers will never use calculus on the job (literally not hard to find one who had a whole career in EE without using calculus). If you're doing research or are at the forefront of a discipline - sure, you'll need calculus. Or if you're doing electromagnetics, etc. The theory is built on calculus, but you don't need to know it to apply the results of the theory. Would it be a red flag if a candidate clearly didn't understand the basics of differentiation (i.e. rate of change) and integrals (i.e. summing quantities)? Perhaps. But should I ask someone to do a tricky integral for an EE role that will not require the person to do any calculus? I would be criticized by my peers, and if I kept doing that I would be excluded from interviewing. In fact, even if I ask them to do non-tricky integrals I would be criticized. Asking people to figure out a trick to solve a linked list problem is equivalent to asking EE candidates to do tricky integrals or differential equations.

t_serpico 6y ago
thats a great analogy