2 ms·
Yeah. I'm much more interested in discovering an interview subject's strengths, so I tend to give broad things that can be solved many ways. One interview I ha
by wpietri 4y ago
Yeah. I'm much more interested in discovering an interview subject's strengths, so I tend to give broad things that can be solved many ways.
One interview I had years ago that I really liked was where they gave a sample of code with a number of issues and asked me to describe how I'd improve it. I really appreciated that a) it was much more like actual work than many questions, b) you could start with obvious things and work deeper, and c) there were many valid ways to improve the code, so you weren't just trying to guess the answer the interviewer had in mind.
- timv 4y agoDo you have a reason to believe (c) is true in practice? I strongly suspect many interviewers (myself included) would have a few "top issues" and significantly favour candidates who pointed them out. But as the candidate you don't really know which issues will seem important to the interviewer. It's not an irrelevant exercise though - code reviews are a real part of many roles and making sensible choices about what to comment on is a necessary skill. But it is hard to avoid turning the interview into an exercise in "guess what's on the top of my list"
- wpietri 4y agoThe first part of (c) is true, so I guess you're asking about how the interviewers would react? These folks were obviously interested in differing approaches; we had a good conversation about it. And that's how I use broad questions. But I agree a huge problem of interviews is the "guess what I'm thinking" interviewer. Most interviewing processes are not primarily about making good hires. They're about making interviewers feel smart and important.