The difference is, in the job interview you’re writing it from scratch yourself. On the job you have to take over from the guy who left 10 years ago and that button was designed in such a way that resizing it will add garbage data to all tables in the database and also send an email to all your customers telling them to switch providers.
Yeah, the difficult bit is never writing new code. It’s maintaining what you have. The ones that bug me are the developers who only build prototypes, impress management, and move on to the next thing before they ever get dragged down into working on production systems. Management always thinks those are the talented ones because they build new stuff, then they never ask anyone but those people to build new stuff, and this confirms their belief that those people have a special talent. The rest of us are just busy translating their toy prototypes into actual production-ready systems and maintaining them.
A more honest code test:
interviewer: “see if you can get this project my nephew made in high school to run”
job: getting the next project their nephew made in high school to run
The “job” panel is inaccurate. It doesn’t show the twenty-five meetings about the button size, the designer sketches on paper, the UX review, the corporate stakeholders sign-off, the Atlassian tickets, the back-and-forth email chain between the graphics person and the developer about generating the properly-sized button image, or the failed accessibility review.
FAANG Companies: We want the best PhD graduates to fill these frontend roles
Later: How come we’ll need all these fancy frontend tech just to make the button bigger?
The second one is much more difficult
I’ve interviewed for the big kahunas and wow the tech interviews were tantamount to hazing. I would never subject myself to that kind of stress again for a “for sure, we’ll call, you did great!” and never hearing back again from the team.
Present day, I’m often refactoring more often than I’m writing new code. I like to think I’m really good at refactoring and architecting, but “dumb programmer tricks” ugh, I don’t have the stomach for that kind of stuff anymore. I provide value but it’s not through solving a three wandering pointers linked list puzzle. I keep our moneymakers shaking with some research on the side.
I know there are some really smart people who eat those puzzles for breakfast, but the correlation between puzzling and being good in the business seems weak at best. I’ve seen some really smart people make some pretty bad decisions.
Yes, there’s a huge disconnect between the jumping through hoops demanded at these interviews and the skills you look for in a useful developer for typical everyday software. I have interviewed other developers and never used any of these kinds of tricks in the interviews because I didn’t think they’d tell me a lot. I’m looking for general intelligence, a sense of the territory, resourcefulness in solving problems, the ability to work with other people, and a sufficient level of coding ability that they’re not going to stumble too much on basic things. I don’t care whether they can write code on paper or whether they carry hundreds of algorithms in their heads, as long they know how to search for what they need and can understand what they read. Sometimes ask a question I know they won’t know the answer to, to see if they can explain how they’d go about solving it, and simple things like “I’d Google it” or “I’d ask my colleagues” are good signs in an answer. Most software development isn’t rocket science and we don’t need to pretend it is.
