5 ms·

Honestly, the "coding" is rarely the issue. For most software engineering roles you generally want someone who can: understand problems, figure out possible sol

Honestly, the "coding" is rarely the issue. For most software engineering roles you generally want someone who can: understand problems, figure out possible solutions, decide on which is best, communicate why it is best and (importantly) be flexible when the company wants you to do some other solution. Meet all those requirements and you are a useful member at most companies. I think a general chat about a broad problem and the interviewee's thought process of how they would approach it can tell you much more than whiteboarding some memorized algorithm.

milchek 7y ago
I completely agree. We had this exact discussion at work the other day. I mentioned to a colleague that what I value most is someone who is creative. There are many candidates out there who know all the buzzwords or can discuss features of a programming language purely from memory, etc. This can make for some impressive interviewing, but it tells nothing of their ability to use that knowledge to solve real problems, or their creativity in how they use their skill and expertise when faced with new dilemmas. Sure, you could contest that the creative side isn’t necessary for certain levels of engineering, or that only tech leads require this as a mandatory trait, but I would argue that it is far more important than what most interviews test - rote memorization.
- adt2bt 7y ago
  I'm right there with you. I am always looking for people who attack problems with new perspectives and, most importantly, can describe to me coherently their thought process and pros/cons of their approach.
  - leghifla 7y ago
    "can describe ... pros/cons of their approach" I've always tried to do that... until recently. With a new recruit, this is the fastest way to nightmare discussions. He always emphasizes the cons of my proposals, and never admit that his proposals also have cons. To be honest, I really think he believes what he says, he seems to not see ahead of time where the blocking points will be. I am now forced to only submit the pros, and prepare an argument for the cons, which is rarely needed. This is not a way to have good technical decisions.
kaetemi 7y ago
Reading code is the biggest problem. Good tests, I find, are to give them a simple piece of code with minimal comments. For example, some non-standard special purpose container implementation. Then ask them to explain what the purpose of the code could be as simply and short as possible. Either - They'll start literally explaining each line of code without understanding the whole. - They completely miss the point. - They at least figure out it's a container of some sorts. - They'll explain technically what it literally does. - They'll give you the academic term for the concept it implements. - They'll actually explain the purpose briefly in simple words. Those last three are good, in different ways. The better ones will also spot the bugs or performance issues in the code.
sjg007 7y ago
True but the whiteboard algorithm problem is supposed to be the proxy for that. then maybe a systems question. I don’t do well at them. I agree that requirements are underrated.
frankzinger 7y ago
> than whiteboarding some memorized algorithm. This is not how it works! There are over 1000 problems on leetcode. Sure, many of them are solved using the same techniques but there is usually a twist and you often need to combine multiple approaches or come up with something new (to you). And then there is usually a very problem-specific way in which the problem can be solved 10 or 50 times faster. Often these insights are very difficult to come up with. The people who created these questions are actually very smart and excepting some of the questions at the easiest level it's usually a far cry from simply implementing Dijkstra from memory!
- lubujackson 7y ago
  I don't intend to say that leetcode/competitive programming is easy, far from it. It is too focused on coding vs. the broader skillset that successful web devs have: working in teams, business objectives, scaling issues, etc. I think even the baseline expectations (lets say remembering how to implement a specific type of sort) are often at odds with how anyone does things in the real world - a few devs are implementing these things by hand for certain reasons but not MOST devs, not even at most FAANG jobs. So why is everyone using that knowledge as a filter? The problem with leetcoding in interviews is that it is easily measurable but not an important metric. Focusing on someone's aptitude at skills they never use at their job means good developers get tossed aside or are forced to waste energy jumping through hoops needlessly.

milchek 7y ago

I completely agree. We had this exact discussion at work the other day. I mentioned to a colleague that what I value most is someone who is creative. There are many candidates out there who know all the buzzwords or can discuss features of a programming language purely from memory, etc. This can make for some impressive interviewing, but it tells nothing of their ability to use that knowledge to solve real problems, or their creativity in how they use their skill and expertise when faced with new dilemmas. Sure, you could contest that the creative side isn’t necessary for certain levels of engineering, or that only tech leads require this as a mandatory trait, but I would argue that it is far more important than what most interviews test - rote memorization.

adt2bt 7y ago
I'm right there with you. I am always looking for people who attack problems with new perspectives and, most importantly, can describe to me coherently their thought process and pros/cons of their approach.
- leghifla 7y ago
  "can describe ... pros/cons of their approach" I've always tried to do that... until recently. With a new recruit, this is the fastest way to nightmare discussions. He always emphasizes the cons of my proposals, and never admit that his proposals also have cons. To be honest, I really think he believes what he says, he seems to not see ahead of time where the blocking points will be. I am now forced to only submit the pros, and prepare an argument for the cons, which is rarely needed. This is not a way to have good technical decisions.

kaetemi 7y ago

Reading code is the biggest problem. Good tests, I find, are to give them a simple piece of code with minimal comments. For example, some non-standard special purpose container implementation. Then ask them to explain what the purpose of the code could be as simply and short as possible. Either - They'll start literally explaining each line of code without understanding the whole. - They completely miss the point. - They at least figure out it's a container of some sorts. - They'll explain technically what it literally does. - They'll give you the academic term for the concept it implements. - They'll actually explain the purpose briefly in simple words. Those last three are good, in different ways. The better ones will also spot the bugs or performance issues in the code.

sjg007 7y ago

True but the whiteboard algorithm problem is supposed to be the proxy for that. then maybe a systems question. I don’t do well at them. I agree that requirements are underrated.

frankzinger 7y ago

> than whiteboarding some memorized algorithm. This is not how it works! There are over 1000 problems on leetcode. Sure, many of them are solved using the same techniques but there is usually a twist and you often need to combine multiple approaches or come up with something new (to you). And then there is usually a very problem-specific way in which the problem can be solved 10 or 50 times faster. Often these insights are very difficult to come up with. The people who created these questions are actually very smart and excepting some of the questions at the easiest level it's usually a far cry from simply implementing Dijkstra from memory!

lubujackson 7y ago
I don't intend to say that leetcode/competitive programming is easy, far from it. It is too focused on coding vs. the broader skillset that successful web devs have: working in teams, business objectives, scaling issues, etc. I think even the baseline expectations (lets say remembering how to implement a specific type of sort) are often at odds with how anyone does things in the real world - a few devs are implementing these things by hand for certain reasons but not MOST devs, not even at most FAANG jobs. So why is everyone using that knowledge as a filter? The problem with leetcoding in interviews is that it is easily measurable but not an important metric. Focusing on someone's aptitude at skills they never use at their job means good developers get tossed aside or are forced to waste energy jumping through hoops needlessly.