binary girl: the secret blog

|

shh!

software engineering: a tip (or two) for the interviewer

March 12th, 2014 at 12:37

Recently I had a funny LinkedIn recruiter email that was so hilariously busy touting the amazingness of this company that I had to follow their advice when they said, “Our employees love us so much, check us out on Glassdoor!”

So, I did, of course, because I wanted to see what their employees were gushingly saying. And, of course, I went to the section for people who had interviewed at the company, and found something startling: a bunch of people interviewing for senior software engineering level positions were reporting having tech screens that included questions like, “What is polymorphism?” and “What are the difference between the private, protected, and public modifiers?”

I’ve done a LOT of interviewing in my day, because I love interviewing people and getting to know them. That said, it seems like an incredibly rookie mistake to fail to moderate your interviewing style based on the role you’re interviewing someone to occupy. When I speak to a senior software engineer, I expect them to be driven, imaginative, creative, and able to lead themselves meaningfully through a project, and if I spend my time speaking to them about the mundanity of software engineering, then I’m missing an incredible opportunity to make sure that they actually fit the role of senior, vs something more junior to that role. The ability to do software engineering at a level above entry has NOTHING to do with the mundanity of a language and EVERYTHING to do with the ability to be handed a problem and to think your way through it.

And before you tell me some horror story you heard once about a guy who got in at CTO-level because of an ineffective interviewing process and a resume full of lies, let me counter with this: when you bring someone in to interview, throw some imagined problem at them on a whiteboard, and see them work through it, you can pretty much assess their ability and whether or not their resume makes sense. And relatedly, PLEASE let’s stop with these ridiculous “implement quicksort” crap questions, unless you’re working somewhere where you suddenly need to reimplement quicksort in some fashion because the version provided to you in the API isn’t fast enough or whatever. Most of the time, we’re solving problems like, “I’m writing an app for fantasy football and need to be able to output a leaderboard, including tie-breakers.”

Maybe next time I do a phone screen and they ask me one of those questions I will just point them to this post.

Leave a Reply

Leave a Reply

Your email address will not be published. Required fields are marked *