|
> I've also found that interviews don't tell you much about reality. Always ask to see code and talk to engineers about what their days look like. I believe there are very few legitimate reasons they won't show you their code, but more likely if they're refusing, it's because they're hiding something. When talking to an engineer, ask them how their code goes from idea to production and have it explained in detail. This will tell you what type of management they have, what testing/review/deployment practices, etc.. As a bonus, I also like to ask my future peers what they don't like about their job or what they'd like to change. I agree most jobs are some form of shite, but there are good ones. Being more picky during the interview phase should hopefully allow you to find some of those while weeding out the bad quicker. |
In a startup, I think I'd have to get an NDA from everyone, even if the code was mindless bulk glue code -- if only to avoid having to later mention that practice to investors who are checking our IP diligence.
Would the following alternative work for you?
In a great engineering environment, people will give sincere answers to questions, or tell you when they can't tell you (because they don't know, or because of business-related conflicts). What about just asking them what their code is like, and see whether their answer sounds like they know what they're talking about, such that that they could give you an accurate answer.
Variation: if they know what they're talking about, but they misrepresented it intentionally, that's a really bad sign from an engineer. And hiring engineers under false pretenses would be a bad idea, as would setting precedent for engineers in that organization intentionally misrepresenting technical information to each other. (That doesn't mean that a dumb organization wouldn't establish an internal culture of dishonesty anyway, but you'll have to filter out the self-destructive and the scammers some other way.)