3 ms·

Thanks for your candor, I generally had this sense. If we had something like, “we usually ask for a take-home but a pointer to a code sample you’d be willing to

by entee 7y ago

Thanks for your candor, I generally had this sense. If we had something like, “we usually ask for a take-home but a pointer to a code sample you’d be willing to discuss will work.” Would that be acceptable? My logic on the take home was that interviews are hard without something to talk about and contrived problems are not super reflective of real work. Therefore, I’d send a dumb version of a simple task we have, then we’d walk through trade offs and such. If I have some code you wrote and can walk me through that’s a very useful datapoint not just for competence (if you’ve been around a while you probably are good) but for personality and how we’d work together. Does that seem more reasonable as a trade off for your time?

Benjammer 7y ago
I think in general all of these things just start to come off as dishonest, when senior engineers think about what makes them feel "senior," or what they respect and value in "senior" colleagues. At some point I think senior engineers realize that coding is the absolute least of your worries as someone expected to do things like interface with the business side, plan medium/long-term roadmaps, improve dev tools or general architecture to make juniors more productive, or mentor/train/manage juniors. When the entire process seems to be heavily weighted towards coding, it gives off the vibe that this is a company that recognizes overworking and churning out code as traits of a senior engineer, instead of shrewd decision-making, efficient delegation, smart scoping of projects, strong leadership skills, etc etc etc. I don't want to spend my free time building a portfolio of random bullshit code any more than I want to spend time on your take home test. Because I can't for the life of me see why having an impressive (or average) github profile should be the leading indicator for senior engineering skills. What is wrong with simple live-coding sessions on very small pieces of code while discussing objectives, edge cases, extensions, etc? Coupled with a high-level systems design session with whiteboard diagrams but no code, and a behavioral interview assessing leadership skills, extracurriculars, personality type, etc. Sane companies seem perfectly fine with sticking to this formula. Where is this idea that we need more and more, deeper and deeper assessment of candidates coming from? What problem(s) is this solving to look at large amounts of pre-written code from candidates?
- entee 7y ago
  That's all very fair. The Q I usually ask of all candidates onsite is a design, "give-me-pseudocode/prototypes/class outlines" question which I find infinitely more useful in probing how someone thinks than whiteboard algorithm/coding qs. And to be clear, I wouldn't want to see BS code, but if someone had contributed to an open source project or had some sort of side project that they would have done anyway, that would have been useful. I think our focus on code was based on the fact that everyone needed to write code. We were a small company so there was less of the architecture work. We may well have benefited from doing more of it, but we still needed people to ship lots of code. You do ask a very important question for which I don't really have an answer: why do we care so much about these take-homes or coding interviews for people who have been around for a while? For me I'd say because I want to have a point of comparison with all other candidates, but that's a pretty weak answer. I'll think more about it.

by entee 7y ago

Benjammer 7y ago

I think in general all of these things just start to come off as dishonest, when senior engineers think about what makes them feel "senior," or what they respect and value in "senior" colleagues. At some point I think senior engineers realize that coding is the absolute least of your worries as someone expected to do things like interface with the business side, plan medium/long-term roadmaps, improve dev tools or general architecture to make juniors more productive, or mentor/train/manage juniors. When the entire process seems to be heavily weighted towards coding, it gives off the vibe that this is a company that recognizes overworking and churning out code as traits of a senior engineer, instead of shrewd decision-making, efficient delegation, smart scoping of projects, strong leadership skills, etc etc etc. I don't want to spend my free time building a portfolio of random bullshit code any more than I want to spend time on your take home test. Because I can't for the life of me see why having an impressive (or average) github profile should be the leading indicator for senior engineering skills. What is wrong with simple live-coding sessions on very small pieces of code while discussing objectives, edge cases, extensions, etc? Coupled with a high-level systems design session with whiteboard diagrams but no code, and a behavioral interview assessing leadership skills, extracurriculars, personality type, etc. Sane companies seem perfectly fine with sticking to this formula. Where is this idea that we need more and more, deeper and deeper assessment of candidates coming from? What problem(s) is this solving to look at large amounts of pre-written code from candidates?

entee 7y ago
That's all very fair. The Q I usually ask of all candidates onsite is a design, "give-me-pseudocode/prototypes/class outlines" question which I find infinitely more useful in probing how someone thinks than whiteboard algorithm/coding qs. And to be clear, I wouldn't want to see BS code, but if someone had contributed to an open source project or had some sort of side project that they would have done anyway, that would have been useful. I think our focus on code was based on the fact that everyone needed to write code. We were a small company so there was less of the architecture work. We may well have benefited from doing more of it, but we still needed people to ship lots of code. You do ask a very important question for which I don't really have an answer: why do we care so much about these take-homes or coding interviews for people who have been around for a while? For me I'd say because I want to have a point of comparison with all other candidates, but that's a pretty weak answer. I'll think more about it.