> Can you elaborate on what you consider "contributing to the engineering of a software product"? and more generally what "software engineering" entails?
Actually, not in a space appropriate for an HN comment. Here's a very brief summary: I think in its current state there is very little actual engineering in this industry. It seems to me to consist of a large number of folks who approach every problem like a CSX01 project. It could move toward a more mature engineering footing if there were less focus on CS trivia and more on broader, deeper understanding of systems and relationships between them.
To be blunt, your "reverse a linked list" question is something I consider an example of the Law of the Instrument (https://en.wikipedia.org/wiki/Law_of_the_instrument): every problem is a CS nail to hit with a CS hammer. It's great for exploring the items you note at a very low, narrowly-scoped, and shallow level. It's not so good for gauging actual problem solving ability or engineering ability.
> How do you interview?
Interviewing is a crap shoot, and my methods are at least as flawed as any others'.
Phone screens with a shared editor are the place I ask questions like yours, except I'm not looking for a correct implementation, complete solution or discussion about it: I'm looking to see if they at least have some vague notion of what writing source code entails (even if it's just because they read about it and memorized it).
At the in-person interview I tend to do two things: discuss in depth a project in the person's past and a higher level discussion about something pertinent to their work at the company. For me the latter has varied from details for some feature to be implemented in a real time system to motivating a data exploration approach in the context of developing a data science product.
> I think in its current state there is very little actual engineering in this industry.
Agreed.
> It's not so good for gauging actual problem solving ability or engineering ability.
Also agree. It is not the only question I ask. However, I only want to hire people who, when the need arises, can actually use a hammer. I am perplexed that people find that offensive.
> At the in-person interview I tend to do two things: discuss in depth a project in the person's past and a higher level discussion about something pertinent to their work at the company. For me the latter has varied from details for some feature to be implemented in a real time system to motivating a data exploration approach in the context of developing a data science product.
Agree. However, I also do some technical parts in person/
Actually, not in a space appropriate for an HN comment. Here's a very brief summary: I think in its current state there is very little actual engineering in this industry. It seems to me to consist of a large number of folks who approach every problem like a CSX01 project. It could move toward a more mature engineering footing if there were less focus on CS trivia and more on broader, deeper understanding of systems and relationships between them.
To be blunt, your "reverse a linked list" question is something I consider an example of the Law of the Instrument (https://en.wikipedia.org/wiki/Law_of_the_instrument): every problem is a CS nail to hit with a CS hammer. It's great for exploring the items you note at a very low, narrowly-scoped, and shallow level. It's not so good for gauging actual problem solving ability or engineering ability.
> How do you interview?
Interviewing is a crap shoot, and my methods are at least as flawed as any others'.
Phone screens with a shared editor are the place I ask questions like yours, except I'm not looking for a correct implementation, complete solution or discussion about it: I'm looking to see if they at least have some vague notion of what writing source code entails (even if it's just because they read about it and memorized it).
At the in-person interview I tend to do two things: discuss in depth a project in the person's past and a higher level discussion about something pertinent to their work at the company. For me the latter has varied from details for some feature to be implemented in a real time system to motivating a data exploration approach in the context of developing a data science product.