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