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?
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.
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?