|
|
|
|
|
by vertis
712 days ago
|
|
20+ YOE. I've never been fond of whiteboard technical interviews which used to be the norm, I really struggle to draw and talk at the same time. I do fine in interviews normally, I tend to be more of a delivering value for the business kind of developer and strongly emphasise this in my interviews. I'm not writing operating systems and neither are most the other people I work with and hire. These days, I don't do leetcode. If a company insists I walk away. I have better things to do with my time than memorise a bunch of useless information (for some value of useless). I'm mostly on the other side of interviews now and am firmly in the belief that you can get a limited set of signals during an interview. The "Thinking Fast and Slow" view is that we're not very good at evaluating people from a gut feeling. You might think this would push me towards leetcode and other quantitive measures, however I'm much more interested in working out whether you can be good on a team. The last thing I want is an asshole 10x engineer that makes everyone else unhappy. If you can't actually program I'm going to work that out by watching your PRs and you won't pass the probation. I'm not suggesting I do NO checking in the interview, just that I put limited stock in what can be read during this process. |
|
Leetcode problems are almost useless for determining what matters in a professional engineer. But the stuff that really matters (communication skill, clarity, patience, flexibility / lack of dogmatism, taste, constructive criticism, political savvy, prioritization of constraints, willingness to write documentation, reading code and finding bugs, etc.) is not something a new-career engineer a few years out of an undergrad CS program can competently evaluate, because they're probably not very good at these things themselves. And in this industry, that's largely who is doing the interviewing.