Most of our interviews are spent reading code, not writing it. We hand a candidate a working piece of someone else's service and ask what they'd want to understand before changing it — because on real projects, the first months of any engagement are spent inside systems somebody else built, and the people who ask good questions there are the ones who don't break things. Writing new code from a blank page is the easiest part of the job and the least of what we hire for. What's the last thing you looked at in your own product and thought: I'd want to know why this was built this way before touching it?
Was this useful?