The Truth About Interviewing
Warning: the title of this blog entry is very slightly misleading. It really ought to be called "The Partial (At Best) and In Any Case Utterly Biased So-Called 'Truth' About Certain Restricted Kinds of Technical Interviewing By a Complete Bigoted Snobby Jerk Who Doesn't Know What He's Talking About Becuz PHP r00lZ And You Don't Need To Know Anything Else!!!!"
However, that was a wee bit too long, so I shortened it. But consider yourself warned. (And yes, I like the longer title better too!)
Anyhoo...
An anonymous coward commented on one of my blogs:
In regards to the interview chronicles regarding how someone was aweful or saved themselves during job interviews, I'd have to say you're a bit of snob aren't you? Granted the people you plan to hire will be paid substantial amounts of money to do good solid work, I think you're the kind of interviewer who tends to mold the people who work under him into little clones of him. "You must know this for me to consider you a 'true engineer' otherwise, I will boot you out the door." I think it's narrow minded and it's a wonder why more people don't go into the technical fields with the people who are currently populating it. Egoists and snobs even if it is deserved.
<satire>
Well said! Except for the last sentence, which is missing a verb, not to mention any semblance of intelligibility. But other than that, I think we should give this commenter a position as the Editor-In-Chief of the New York Times.
As it happens, I'm in the same boat as the commenter. Really.
See, I've always thought it would be cool to be an airline pilot. But I went to interview for the position, and those damn snobs wanted me to be a miniature clone of their totally biased idea of an "ideal airline pilot." They expected me to know all this crapola about meteorology and electrical engineering and other stuff that obviously has nothing to do with flying a plane. Plus I had to have all these flight hours logged, I mean you just wouldn't believe the requirements. This was obviously just an "old boys" network trying to keep honest people like me out. I'm surprised anyone gets into that field at all.
So then I thought, maybe I should go be a brain surgeon. But they wouldn't even let me apply! They snobbily told me that I had to know a whole bunch more about brains, and surgery, and stuff. I've had high school biology, during which I dissected a frog, plus I'm generally a careful guy. I'm smart, and my hands don't shake much, and I can figure stuff out when I need to. And I was really motivated to do brain surgery. But they didn't consider me "true" brain surgeon material. Of all the nerve! I think those surgical interviewers are just cold-blooded snobs. They don't appreciate my true talents. They just want pathetic little clones of the existing brain surgeons out there.
Those hospital and airline directors aren't the only snobs out there, either, I can tell you from personal experience. See, I can juggle five balls pretty well (here's a short video of me doing it), and yet every time I apply for a position in Cirque du Soleil, I don't even get a reply from them! Talk about snobbery. They don't even write back. What's wrong with my juggling? Nothing! They just want a pretty little clone of Viktor Kee. Granted, they're going to pay their jugglers a lot of money to do good solid work, but I think they're the being fairly narrow-minded by not considering me.
Then I wrote a bunch of letters to Hollywood movie studios, offering to be an animal trainer, since I have a Shih Tzu named Cino, and I can get him to sit sometimes. I mean, that took a lot of work! That little dog hardly listens to a word I say. So I feel pretty qualified to be an animal trainer. Sure, I've never worked directly with a bear or a tiger before, but it can't be all that different. You just shout SIT! and then throw them a biscuit when they finally do it, right? Like, a bear-biscuit or a tiger-biscuit instead of a dog biscuit, but other than that it's gonna be the same, I just know it. But those animal-trainer egoists just booted me right out the door.
So I pondered it, and I thought: you know, I'm not going to go into a field full of egotistical airline pilots and brain surgeons and circus performers and animal trainers. They're just trying to sculpt little perfectly-moulded clones of themselves. Screw them!
I made sure to give them an earful by commenting on all their blogs, anonymously. That'll show 'em! I feel much better for telling them what a bunch of brain animal flying juggling surgery training JERKS they all are. I also left out some verbs, just to throw 'em for a loop. Deserved ego they it even wankers.
So yeah, Mr. Commenter. You've got it pegged. Snob city!
</satire>
A Minor (But Popular) Misconception
Before we get started with the real blog entry, let's get this cleared up: managers aren't the only people who interview you. Most interview loops are conducted by engineers who will be working on the same team as you. Nobody works for me, but my company still makes me interview people.
So we don't want little clones working for us; we want them working with us. </really-end-satire-now>
The Harsh Reality
If you want a job at a company like Microsoft, Yahoo!, Apple, or Amazon.com, they're going to have high standards. It doesn't matter if you "know how to program". They're going to test you on algorithmic complexity analysis, advanced data structures, algorithm design, searching and sorting, internationalization techniques, network protocols, OS-level memory management, parsing and semantic analysis, recursion and mathematical induction, graph theory, combinatorics, programming language theory, machine architecture, discrete math and logic, graphics and window systems, fonts and typesetting, color spaces and representations, databases and query languages, filesystems and storage, embedded systems, device drivers, mobile and wireless protocols, and internet standards and technologies.
If you're lucky, that is.
If you're unlucky, they'll ask you to derive the outline of their Ph.D. thesis on fault-tolerant massively parallel machine-learning systems. Or to solve a grand-unification style computation problem involving telephone switches, grid networks, and third-degree differential equations. Or, God forbid, they'll ask you about the darkest corners of C++ syntax.
And you want to know why they'll ask you about that stuff? Because they're using it every day. They've tried hiring people who don't know this stuff. Believe me, they try all the time. They want to hire more programmers, and they're out there on the constant lookout for new meat. But when they lower their standards, they get burned. The 747 crashes, the patient dies, the juggler drops a bowling pin on someone's head, the tiger rips someone's throat out. In the software world: the service goes down for days, losing them millions; the project gets delivered late or even not at all, losing them contracts and customers; they lose the business battle to competitors who hired better engineers.
Putting together a pretty Ruby on Rails site is no small feat. Learning to program is no small feat. Many people try and fail to get even that far. But it's 3- to 5-ball juggling, and it just doesn't cut it for the Cirque du Soleils and private hospitals of the software industry. I'm sure you want to be a racecar driver, a hang-gliding instructor, a corporate lawyer, a movie sound editor, a rocket scientist. But you know you don't have the requisite training or experience. Why do you think knowing a little (or even a lot) about programming automatically qualifies you to get hired at Microsoft?
Software companies have excruciatingly high standards, just like any other profession. Those that don't get eaten up by those that do.
Interviewers can't probe on all the important material in an interview — at least, not the way interviews are conducted in our industry today. So they use sampling. They ask a few breadth questions, to get a feel for how well you know the space we're in, and they ask a few depth questions, to see how well you can think on your feet, apply what you know, and come up with creative solutions to problems similar to the ones they encounter daily.
Or so the theory goes. Interviewing is necessarily fairly artificial. I'm not a big fan of the interviewing approach everyone uses, but there's nothing I personally can do about it. So I do my best to evaluate the software equivalents of brain surgeons and rocket scientists by chatting with them for 45 minutes. I have no other choice, nor does any other interviewer out there.
Well, that's not entirely true; there is one thing I can do about it: I can talk about it. I'm as open about the process as anyone I know, and I've blogged about it from time to time. I assure you that my interviewing style is not substantively different from the styles of thousands of interviewers at hundreds of high-tech companies.
If anything, I'm nicer, because I count motivation (that is, the desire to improve oneself) higher than any other factor in an interview. It's how I've managed to get hired at most of my jobs: my enthusiasm showed through, and was sufficient to cover my inevitable mistakes. So I tend to go a lot easier on candidates who show me they're on an upward curve, as opposed to just coasting.
But not all interviewers are nice, and I know lots and lots of interviewers, at many companies, who've decided that they can fully evaluate you based on whether you can solve some particular convex optimization problem (or graph-search problem, or logic problem, or whatever their pet Elephant Question is), and they ask every candidate this question regardless of their background or experience. In fact, I'd estimate that some 10% of all technical interviewers ask the same questions, year after year, and they could care less about your experience.
You should consider yourself lucky that I talk about this process at all, because most companies treat their interviewing strategy as some sort of proprietary secret, and it's hard to get information about it, unless you want to go interview at a bunch of places.
Hint to companies: you're all doing it the same way. Quit being so frigging secretive about it.
The reason I write about it is that I'm very interested in the whole process:
However, talking about it openly gets people amazingly upset. Many people seem to suffer from selective hearing in this space.
For one thing, people want jobs, and so any hint that someone out there, somewhere, might be asking questions to which they don't know the answers sends them into a spittle-emitting rage. Oddly, they don't seem to mind that they can't get hired as a brain surgeon or an animal trainer. But they think knowing a little programming means they should be a shoo-in for any tech company in the world, and anyone who asks something they don't know is a big mean jerk! (I actually discovered this lovely sentiment after posting recently to the O'Reilly Ruby Blog, so our Anonymous Coward is far from alone in his opinion.)
A friendly note to the Spittle People: Not all software development is the same. Think about that for a sec. You may be really good at web development, but that almost certainly doesn't qualify you to work on an OS kernel. Or you may be really good at OS kernels, but that almost certainly doesn't qualify you to be good at web development.
Our industry has fragmented, just the way the medical industry has, and there are different job roles now. Unless you understand this, you're going to be upset whenever a technical interviewer talks about something you're unfamiliar with. If so, take a deep breath and relax, because they're not talking about your skill set. They're talking about jugglers or hang gliding or something that sounds like what you do, but it's different. You can always go find an interviewer who will probe you on what you care about.
Another group of people who gets upset is other interviewers, because it's very much a stylistic thing. There are no proven techniques in interviewing, and personally I think it's something of a crapshoot. But most interviewers with a reasonable amount of experience seem to think they "have it down", and they think that when I talk about my style, I'm advocating that they change their style. And then they emit plenty of spittle too.
Well, wake up, angry people! There are hundreds of companies conducting technical interviews out there. They're doing it for different job roles, including DBAs, sysadmins, web programmers, unix programmers, windows programmers, java programmers, mobile-device programmers, and many other roles besides. For any given job role, they're all doing it about the same. It's not just me. In fact, those interviewers are YOU, once you get the job.
So if you think you can't get hired into a job you want, be it a software engineer at Boeing or an airline pilot for American, don't tell me about it. Whining at me isn't going to change the realities of our industry. Just go study whatever it is they want you to know.
Finding a Better Job
With all that said, you might wonder whether you want to work at a big software company in the first place. You need to think carefully about your motivations.
If you just want to make money, you can almost certainly find a job that's less technically demanding (or that's technically demanding in different ways) than working at companies like Microsoft. To cite just one of many, many possibilities: you can pick up enough PHP and MySQL to design websites, and go find a desperate hospital or insurance company or school system in need of a web presence, and no doubt it'll pay the bills just as well as Microsoft does.
If money's all you're after, you certainly don't need a computer science degree. Our industry desperately needs more programmers to crank out application code in C#, Java, PHP, Perl, C++, and other popular languages. If you go learn one or two of those languages, you're probably already a shoo-in for many companies.
You should be aware that working at most large tech companies isn't very glamorous, at least not as much as it seems from the outside. For instance, I know a lot of people who love video games, so they assume that game programming must be the most fun kind of programming out there. Then they go get jobs at a huge, mainstream game publisher, only to find that it's actually a bunch of tedious, schedule-driven work, just like the work at all other software companies.
The reality is, delivering good software just keeps getting harder, as customer expectations go up. That's why companies have to be so selective when they're interviewing. Big companies have serious challenges that aren't encountered by smaller companies, including the combinatorial communication (and dependencies) explosion, the need to maintain large legacy code bases, the problems of culture change as the company grows, and the need to find entirely new revenue streams in the face of pressure from Wall Street.
So most big companies are looking for a combination of skills: they need a mix of junior-ish people to help keep the business alive, and senior-ish people to try to help hoist them out of the holes they've dug for themselves internally by growing too fast.
Neither of those sounds very glamorous, does it? In practice, a startup is much more glamorous. You move faster; you're working on a leading-edge idea; you're burning as fast as you can to keep ahead of your competitors and your investor-imposed schedules. You can get brilliant things working, and worry about scaling them and maturing them later. All the fun part is in the startup days.
The trade-off is that you take on a great deal more risk. With a big company, you've got stability, and there's something to be said for that. A few failed startups can make just about anyone pretty risk-averse, at least for a while.
So you have to decide what you want. But like it or not, if you want to work as a software engineer for a big, top-tier, famous tech company, they're going to interview the living hell out of you. Even if you're really good, there's a chance you won't make it in the door.
You do have a certain amount of control over the situation, and this control is NOT something you exercise by commenting angrily on my blogs.
How do you participate in change? Well, first do some research. It's pretty easy to figure out what a company is interviewing for, and what the interviewers are going to be like. Just read the job descriptions on their website. They're usually pretty up-front, saying things like "B.S. in computer science, or equivalent", or they'll tell you exactly which tools and technologies they expect you to have mastered. If you're considering a particular company, then before you interview you should ask your recruiting contact there what kinds of questions to expect from the interview process.
If a company's going to ask you questions that you don't think matter, then don't work there! If you're right, then they'll go out of business, eventually. Or at least you can go throw your weight behind a company that you think has priorities aligned with your own. Vote with your feet!
Once you've actually started working somewhere, you'll eventually have to do interviews of your own. If you don't like their interviewing process, make a stink about it, and maybe they'll listen. Companies don't want false positives or false negatives any more than you do. If you have a great idea for improving the process, let them know. There are all kinds of minor variations you can try. Or maybe you can all agree to experiment with an entirely new process, and see how the resulting hires measure up.
I want to nitpick anyway!
Well, go ahead and comment; that's why I've opened this blog up for anonymous comments. So far, anyway. But blog comments don't actually carry much weight.
If you really want to make a difference, and start changing peoples' minds, go set up your own blog, and express your well-considered opinions there. It's free, and it's easy, and we ALL have access to self-publishing now. If you want to set up an alternate school of interviewing thought, well, I'm quite happy to read what you have to say. Seems like almost anything would be better than the mess we have with interviewing today.
The truth about interviewing is that everyone does it their own way, and it's always about the same: people interview for what they know. Nobody's very good at interviewing for skills they don't know, so the tendency to produce clones is actually quite widespread — the commenter had at least that much right. The best most of us can do is at least try to hire high-quality, generalist clones who pose the least risk of tiger throat-ripping software outages if they're hired.
But please: if you don't know something, don't go bersek on us. Just go read about it on Wikipedia. It's not as hard as you think!
However, that was a wee bit too long, so I shortened it. But consider yourself warned. (And yes, I like the longer title better too!)
Anyhoo...
An anonymous coward commented on one of my blogs:
In regards to the interview chronicles regarding how someone was aweful or saved themselves during job interviews, I'd have to say you're a bit of snob aren't you? Granted the people you plan to hire will be paid substantial amounts of money to do good solid work, I think you're the kind of interviewer who tends to mold the people who work under him into little clones of him. "You must know this for me to consider you a 'true engineer' otherwise, I will boot you out the door." I think it's narrow minded and it's a wonder why more people don't go into the technical fields with the people who are currently populating it. Egoists and snobs even if it is deserved.
<satire>
Well said! Except for the last sentence, which is missing a verb, not to mention any semblance of intelligibility. But other than that, I think we should give this commenter a position as the Editor-In-Chief of the New York Times.
As it happens, I'm in the same boat as the commenter. Really.
See, I've always thought it would be cool to be an airline pilot. But I went to interview for the position, and those damn snobs wanted me to be a miniature clone of their totally biased idea of an "ideal airline pilot." They expected me to know all this crapola about meteorology and electrical engineering and other stuff that obviously has nothing to do with flying a plane. Plus I had to have all these flight hours logged, I mean you just wouldn't believe the requirements. This was obviously just an "old boys" network trying to keep honest people like me out. I'm surprised anyone gets into that field at all.
So then I thought, maybe I should go be a brain surgeon. But they wouldn't even let me apply! They snobbily told me that I had to know a whole bunch more about brains, and surgery, and stuff. I've had high school biology, during which I dissected a frog, plus I'm generally a careful guy. I'm smart, and my hands don't shake much, and I can figure stuff out when I need to. And I was really motivated to do brain surgery. But they didn't consider me "true" brain surgeon material. Of all the nerve! I think those surgical interviewers are just cold-blooded snobs. They don't appreciate my true talents. They just want pathetic little clones of the existing brain surgeons out there.
Those hospital and airline directors aren't the only snobs out there, either, I can tell you from personal experience. See, I can juggle five balls pretty well (here's a short video of me doing it), and yet every time I apply for a position in Cirque du Soleil, I don't even get a reply from them! Talk about snobbery. They don't even write back. What's wrong with my juggling? Nothing! They just want a pretty little clone of Viktor Kee. Granted, they're going to pay their jugglers a lot of money to do good solid work, but I think they're the being fairly narrow-minded by not considering me.
Then I wrote a bunch of letters to Hollywood movie studios, offering to be an animal trainer, since I have a Shih Tzu named Cino, and I can get him to sit sometimes. I mean, that took a lot of work! That little dog hardly listens to a word I say. So I feel pretty qualified to be an animal trainer. Sure, I've never worked directly with a bear or a tiger before, but it can't be all that different. You just shout SIT! and then throw them a biscuit when they finally do it, right? Like, a bear-biscuit or a tiger-biscuit instead of a dog biscuit, but other than that it's gonna be the same, I just know it. But those animal-trainer egoists just booted me right out the door.
So I pondered it, and I thought: you know, I'm not going to go into a field full of egotistical airline pilots and brain surgeons and circus performers and animal trainers. They're just trying to sculpt little perfectly-moulded clones of themselves. Screw them!
I made sure to give them an earful by commenting on all their blogs, anonymously. That'll show 'em! I feel much better for telling them what a bunch of brain animal flying juggling surgery training JERKS they all are. I also left out some verbs, just to throw 'em for a loop. Deserved ego they it even wankers.
So yeah, Mr. Commenter. You've got it pegged. Snob city!
</satire>
A Minor (But Popular) Misconception
Before we get started with the real blog entry, let's get this cleared up: managers aren't the only people who interview you. Most interview loops are conducted by engineers who will be working on the same team as you. Nobody works for me, but my company still makes me interview people.
So we don't want little clones working for us; we want them working with us. </really-end-satire-now>
The Harsh Reality
If you want a job at a company like Microsoft, Yahoo!, Apple, or Amazon.com, they're going to have high standards. It doesn't matter if you "know how to program". They're going to test you on algorithmic complexity analysis, advanced data structures, algorithm design, searching and sorting, internationalization techniques, network protocols, OS-level memory management, parsing and semantic analysis, recursion and mathematical induction, graph theory, combinatorics, programming language theory, machine architecture, discrete math and logic, graphics and window systems, fonts and typesetting, color spaces and representations, databases and query languages, filesystems and storage, embedded systems, device drivers, mobile and wireless protocols, and internet standards and technologies.
If you're lucky, that is.
If you're unlucky, they'll ask you to derive the outline of their Ph.D. thesis on fault-tolerant massively parallel machine-learning systems. Or to solve a grand-unification style computation problem involving telephone switches, grid networks, and third-degree differential equations. Or, God forbid, they'll ask you about the darkest corners of C++ syntax.
And you want to know why they'll ask you about that stuff? Because they're using it every day. They've tried hiring people who don't know this stuff. Believe me, they try all the time. They want to hire more programmers, and they're out there on the constant lookout for new meat. But when they lower their standards, they get burned. The 747 crashes, the patient dies, the juggler drops a bowling pin on someone's head, the tiger rips someone's throat out. In the software world: the service goes down for days, losing them millions; the project gets delivered late or even not at all, losing them contracts and customers; they lose the business battle to competitors who hired better engineers.
Putting together a pretty Ruby on Rails site is no small feat. Learning to program is no small feat. Many people try and fail to get even that far. But it's 3- to 5-ball juggling, and it just doesn't cut it for the Cirque du Soleils and private hospitals of the software industry. I'm sure you want to be a racecar driver, a hang-gliding instructor, a corporate lawyer, a movie sound editor, a rocket scientist. But you know you don't have the requisite training or experience. Why do you think knowing a little (or even a lot) about programming automatically qualifies you to get hired at Microsoft?
Software companies have excruciatingly high standards, just like any other profession. Those that don't get eaten up by those that do.
Interviewers can't probe on all the important material in an interview — at least, not the way interviews are conducted in our industry today. So they use sampling. They ask a few breadth questions, to get a feel for how well you know the space we're in, and they ask a few depth questions, to see how well you can think on your feet, apply what you know, and come up with creative solutions to problems similar to the ones they encounter daily.
Or so the theory goes. Interviewing is necessarily fairly artificial. I'm not a big fan of the interviewing approach everyone uses, but there's nothing I personally can do about it. So I do my best to evaluate the software equivalents of brain surgeons and rocket scientists by chatting with them for 45 minutes. I have no other choice, nor does any other interviewer out there.
Well, that's not entirely true; there is one thing I can do about it: I can talk about it. I'm as open about the process as anyone I know, and I've blogged about it from time to time. I assure you that my interviewing style is not substantively different from the styles of thousands of interviewers at hundreds of high-tech companies.
If anything, I'm nicer, because I count motivation (that is, the desire to improve oneself) higher than any other factor in an interview. It's how I've managed to get hired at most of my jobs: my enthusiasm showed through, and was sufficient to cover my inevitable mistakes. So I tend to go a lot easier on candidates who show me they're on an upward curve, as opposed to just coasting.
But not all interviewers are nice, and I know lots and lots of interviewers, at many companies, who've decided that they can fully evaluate you based on whether you can solve some particular convex optimization problem (or graph-search problem, or logic problem, or whatever their pet Elephant Question is), and they ask every candidate this question regardless of their background or experience. In fact, I'd estimate that some 10% of all technical interviewers ask the same questions, year after year, and they could care less about your experience.
You should consider yourself lucky that I talk about this process at all, because most companies treat their interviewing strategy as some sort of proprietary secret, and it's hard to get information about it, unless you want to go interview at a bunch of places.
Hint to companies: you're all doing it the same way. Quit being so frigging secretive about it.
The reason I write about it is that I'm very interested in the whole process:
- I want to become a better interviewer myself.
- I want to improve the process overall, as it's far from perfect.
- I want to help candidates prepare better for their interviews.
However, talking about it openly gets people amazingly upset. Many people seem to suffer from selective hearing in this space.
For one thing, people want jobs, and so any hint that someone out there, somewhere, might be asking questions to which they don't know the answers sends them into a spittle-emitting rage. Oddly, they don't seem to mind that they can't get hired as a brain surgeon or an animal trainer. But they think knowing a little programming means they should be a shoo-in for any tech company in the world, and anyone who asks something they don't know is a big mean jerk! (I actually discovered this lovely sentiment after posting recently to the O'Reilly Ruby Blog, so our Anonymous Coward is far from alone in his opinion.)
A friendly note to the Spittle People: Not all software development is the same. Think about that for a sec. You may be really good at web development, but that almost certainly doesn't qualify you to work on an OS kernel. Or you may be really good at OS kernels, but that almost certainly doesn't qualify you to be good at web development.
Our industry has fragmented, just the way the medical industry has, and there are different job roles now. Unless you understand this, you're going to be upset whenever a technical interviewer talks about something you're unfamiliar with. If so, take a deep breath and relax, because they're not talking about your skill set. They're talking about jugglers or hang gliding or something that sounds like what you do, but it's different. You can always go find an interviewer who will probe you on what you care about.
Another group of people who gets upset is other interviewers, because it's very much a stylistic thing. There are no proven techniques in interviewing, and personally I think it's something of a crapshoot. But most interviewers with a reasonable amount of experience seem to think they "have it down", and they think that when I talk about my style, I'm advocating that they change their style. And then they emit plenty of spittle too.
Well, wake up, angry people! There are hundreds of companies conducting technical interviews out there. They're doing it for different job roles, including DBAs, sysadmins, web programmers, unix programmers, windows programmers, java programmers, mobile-device programmers, and many other roles besides. For any given job role, they're all doing it about the same. It's not just me. In fact, those interviewers are YOU, once you get the job.
So if you think you can't get hired into a job you want, be it a software engineer at Boeing or an airline pilot for American, don't tell me about it. Whining at me isn't going to change the realities of our industry. Just go study whatever it is they want you to know.
Finding a Better Job
With all that said, you might wonder whether you want to work at a big software company in the first place. You need to think carefully about your motivations.
If you just want to make money, you can almost certainly find a job that's less technically demanding (or that's technically demanding in different ways) than working at companies like Microsoft. To cite just one of many, many possibilities: you can pick up enough PHP and MySQL to design websites, and go find a desperate hospital or insurance company or school system in need of a web presence, and no doubt it'll pay the bills just as well as Microsoft does.
If money's all you're after, you certainly don't need a computer science degree. Our industry desperately needs more programmers to crank out application code in C#, Java, PHP, Perl, C++, and other popular languages. If you go learn one or two of those languages, you're probably already a shoo-in for many companies.
You should be aware that working at most large tech companies isn't very glamorous, at least not as much as it seems from the outside. For instance, I know a lot of people who love video games, so they assume that game programming must be the most fun kind of programming out there. Then they go get jobs at a huge, mainstream game publisher, only to find that it's actually a bunch of tedious, schedule-driven work, just like the work at all other software companies.
The reality is, delivering good software just keeps getting harder, as customer expectations go up. That's why companies have to be so selective when they're interviewing. Big companies have serious challenges that aren't encountered by smaller companies, including the combinatorial communication (and dependencies) explosion, the need to maintain large legacy code bases, the problems of culture change as the company grows, and the need to find entirely new revenue streams in the face of pressure from Wall Street.
So most big companies are looking for a combination of skills: they need a mix of junior-ish people to help keep the business alive, and senior-ish people to try to help hoist them out of the holes they've dug for themselves internally by growing too fast.
Neither of those sounds very glamorous, does it? In practice, a startup is much more glamorous. You move faster; you're working on a leading-edge idea; you're burning as fast as you can to keep ahead of your competitors and your investor-imposed schedules. You can get brilliant things working, and worry about scaling them and maturing them later. All the fun part is in the startup days.
The trade-off is that you take on a great deal more risk. With a big company, you've got stability, and there's something to be said for that. A few failed startups can make just about anyone pretty risk-averse, at least for a while.
So you have to decide what you want. But like it or not, if you want to work as a software engineer for a big, top-tier, famous tech company, they're going to interview the living hell out of you. Even if you're really good, there's a chance you won't make it in the door.
You do have a certain amount of control over the situation, and this control is NOT something you exercise by commenting angrily on my blogs.
How do you participate in change? Well, first do some research. It's pretty easy to figure out what a company is interviewing for, and what the interviewers are going to be like. Just read the job descriptions on their website. They're usually pretty up-front, saying things like "B.S. in computer science, or equivalent", or they'll tell you exactly which tools and technologies they expect you to have mastered. If you're considering a particular company, then before you interview you should ask your recruiting contact there what kinds of questions to expect from the interview process.
If a company's going to ask you questions that you don't think matter, then don't work there! If you're right, then they'll go out of business, eventually. Or at least you can go throw your weight behind a company that you think has priorities aligned with your own. Vote with your feet!
Once you've actually started working somewhere, you'll eventually have to do interviews of your own. If you don't like their interviewing process, make a stink about it, and maybe they'll listen. Companies don't want false positives or false negatives any more than you do. If you have a great idea for improving the process, let them know. There are all kinds of minor variations you can try. Or maybe you can all agree to experiment with an entirely new process, and see how the resulting hires measure up.
I want to nitpick anyway!
Well, go ahead and comment; that's why I've opened this blog up for anonymous comments. So far, anyway. But blog comments don't actually carry much weight.
If you really want to make a difference, and start changing peoples' minds, go set up your own blog, and express your well-considered opinions there. It's free, and it's easy, and we ALL have access to self-publishing now. If you want to set up an alternate school of interviewing thought, well, I'm quite happy to read what you have to say. Seems like almost anything would be better than the mess we have with interviewing today.
The truth about interviewing is that everyone does it their own way, and it's always about the same: people interview for what they know. Nobody's very good at interviewing for skills they don't know, so the tendency to produce clones is actually quite widespread — the commenter had at least that much right. The best most of us can do is at least try to hire high-quality, generalist clones who pose the least risk of tiger throat-ripping software outages if they're hired.
But please: if you don't know something, don't go bersek on us. Just go read about it on Wikipedia. It's not as hard as you think!
posted by Steve Yegge at 8:33 PM
31 Comments:
You say that "all the companies are interviewing like this", but my company doesn't allow quiz-style interviews, for fear of discrimination lawsuits or something silly like that. We pay for it by hiring a lot of duds, but no one wants to admit it. Management just keeps throwing people at the problem, and wondering why the projects don't improve.
Do you have any ideas on how to decide whether to hire someone as a programmer when you're not allowed to ask them to write some code?
First anonymous:
If you really can't ask technical questions of interviewees then why not just pick the top N resumes (where the best resumes are based on projects worked on being similar to the project you are hiring for. Then take the names of the candidates from these top N resumes and write them on slots of a roulette wheel (giving each an equal portion of the wheel).... spin the wheel a hundred times and hire the candidate the ball landed on most often. Mone Carlo hiring! You could even automate the process by writing a program to simulate the roulette wheel selection - no need to manually spin a wheel 100 times! To be honest, I'm not sure this method of hiring wouldn't be just about as effective as the current interview-based method. Just think of how much time it would save both interviewers and interviewees.
Now here's the interesting thing about this proposal: while many candidates complain about being asked 'difficult questions' which they feel are not relevant, many of these same candidates will also be offended if you were to tell them that the hiring selection will be made by an entirely random process.
I think the better answer to the hiring problem in general is an audition-based process where you have the most promising N candidates (based on resumes and a phone screen) come in and actually work for a few days. It may well be that the guy/gal who would do terrible in an interview because of nerves could be the best one for the job based on actual job performance. Conversely, someone who might ace your interview might not actually be very good at real work. Yes, the audition-based hiring process would take longer. If you have 5 promising candidates and you want each of them to audition for 3 days it's going to take at least 15 days to figure out which one you will hire. But maybe it would be time well-spent...
Another thought: I'm terrible at coding on a whiteboard and I suspect I'm not alone. No, I don't mean block diagramming, I mean actual coding - nobody does that in real life. However, I've often been asked in an interview to write the code for a problem on a whiteboard. In real life when a new problem comes up that I need to solve in code I might go to a whiteboard to do a block diagram or a state diagram, but then I go and do the coding on a computer and rely on a compiler to tell me if I've got errors. So how hard would it be Interviewers (hint, hint) to have a laptop handy in the interview room which has a plethora of editors on it (at least vi and emacs ;-) and compilers/interpreters for the languages of interest. And then when you ask the candidate to write code to solve a problem you offer the candidate the use of the laptop. With vi and gcc and maybe gdb I could get through a programming problem a lot faster than I can on a white board and as a bonus, you the interviewer could see that I know how to compile a program and interpret error messages in addition to the actual coding.
The acid test I am currently using is pair programming. If you can have your candidate for a few hours to work together on a section of code you can find out how they think, how quickly they pick up the problem domain, how well they communicate, and if they can contribute.
I'm terrible at coding on the whiteboard too. I was shocked at how bad I was, last time I interviewed. This is a really unfortunate way to interview people (but it's amazingly widespread.)
Do you think interviewers take projects you have done your self into account? Written patches for Open source projects/your own shareware project etc. I am not expecting to walk into a technical programming job without the proper experience but I would like to get a foot on the ladder and make it there someday.
Jon.
I ask candidates to write code on a white board, but I let them warm up to it. I start with questions like, "if I execute these 5 lines, in this sequence, what happens?" Then I move to, "find the bugs in this function". Finally they get, "re-write the function using recursion (or whatever)." By that time they've seen enough code that they aren't starting completely cold.
I spend 90 minutes doing an interview. I couldn't imagine doing it in less and my management wouldn't allow much more.
Great blog, I wish I could write that well.
I dont'know how the situation in the US is, but here in Europe it is pretty relaxed. Currently I am working (knock on wood)for a top tech company. Actually it is in the top 3 of telco's in the world. Not working directly for them, but still after 17 months it has become more then a temp job. They even let me deal with important customers now.
So everything is pretty great. However, their interviewing procedure was a joke. There was a techical guy with a spreadsheet containing all their technical requirements. He asked some simple yes/no questions - like do you know J2SE and that was basically it. Probably you think that this was a junior position or that there is an enormous shortage of programmers, but that is not the case.
Maybe this is just an exception to the rule - don't know. To this day I haven't been asked to solve difficult programming puzzles during an interview.
I wrote an article not long ago for TechRepublic.com titled "The Best Software Developers are Built not Bought" (http://techrepublic.com.com/5100-3513_11-6038687.html).
I mention this because many of the same challenges you deal with in this post are the same ones that I struggle with. How do you quickly and (here's the rub) accurately assess how someone will develop software.
Nice Post.
long but very interesting. i just had a phone screen and it turned out to be aloit less scary than i had thought. considering the top company. just read guy k's blog about it and there is a description on how HP does interviews. very very through... http://blog.guykawasaki.com/ (art of recruiting part2)
in 15 years of it work i have never once been asked to write code during interview. never. i was often perpared to but never happend. but then i never went for the top of the top jobs. it's like steve says. one must know what one wants in the first place...
Last Thursday I was faced with the all too uncomfortable prospect of writing code on a whiteboard for an interview.
I think I did... ehh, okay. Not as good as I would've hoped. I made a number of mistakes across the three technical interviews I did, but I don't think any of them were that terrible.
Some things I decided that I'd do the next time I got a request to do that:
1) Before taking the erasable marker in hand, I'm going to write out my plan on paper before even thinking about writing code. Just a prose description of what the alogrithm is going to do. The reason being that I got up to the board and felt scared because I didn't immediately have the algorithm ready to go. I think it's reasonable to take at least 5 minutes before commiting yourself to fake code to figure out what you want to write and find the fundamental problems with your initial ideass. The other advantage is that if you've written out basically what you want it to do, you might be able to decide on an optimal paradigm, even if that choice is as simple as iterative versus recursive.
2) Probe the test cases of the input that the interviewer gives you. This one inparticular I wish I'd done. I'd come to the last line of the algorithm and then say out loud, "I think I'm done..." then instantly regret it because whoops, there's 5 boundary cases I forgot about in my rush to get the general case written as fast as possible. I don't think it's necessary to write fake code that tests the boundaries, but to just write out some examples of the boundaries in the first place.
3) Don't put types (int, char, etc, etc) on anything until you have to. I managed to do this on the third interview because I've been writing Ruby for the past year and I realized that typing things prematurely is a detriment if you don't know precisely how something is going to work. The one example I did this on worked out very well, because I'm pretty sure I would've made a bunch of typing mistakes if I'd written the types down in order (like I did on the other two that I had to correct). The interviewer wasn't really sure what I was doing while I was doing it, but it all worked out in the end.
I think if I ever end up in an interviewing position, I'd want to try and reduce the anxiety of the situation by telling the candidate to not worry too much about the specifics and that I just wanted to see how they reasoned about code (even if it wasn't true). I wasn't really all that scared, but doing code up on a whiteboard where you can't verify if you're correct because there's no unit testing software to tell you that you've at least found solutions for all the boundaries that you've thought of or can use inverse relations to check your work is a bit like walking a tight-rope.
This very morning during an interview I was asked to write a threaded cache class, implemented through a singleton to access a database with, wait for it, pen and paper. Have you ever tried writing code with pen and paper? Go ahead, try it. One thing they are not testing is coding ability.
The author genuinely believes that the top tech companies do a good job at interviewing but it just isn't true.
In an ideal world, it would be true. Even in this world, top tech companies wish it was true. And, on the whole, top tech companies work very hard to try to make it true. But they fail. Almost completely. The previous commenter who wrote about the "Monte Carlo" method is closer to correct than the author is.
If an applicant fails to get a job with Microsoft, that isn't a dig against the applicant. Take heart: Microsoft is a company run by humans and humans often make bad or random decisions. That's just human nature. If you try again a few times, you might get hired.
On the lighter side, Microsoft and Google are in a race to have the worst recruiting system in the industry. It's strange: they both have terrible recruiting systems but they are entirely opposite. On one hand, Microsoft recruiting is all about bureaucracy. They've got this elaborate web site that pushes NDAs, drug test and background check approvals and a bunch of other bureaucratic red tape at you while a staffer e-mails you maps to the wrong campus and calls you by the wrong name. On the other hand, Google recruiting is all about randomness. They zip you through, give you an offer ... and then withdraw it. If you complain, they offer to interview you again for the same job. I'm not sure who's going to win but we can draw at least one conclusion: being a top tech company isn't any guarantee that they are good at interviewing.
I wonder if there is a correlation between being a top tech company and being bad at interviewing?
Out of curiosity, how do you manage to make them aware of your enthusiasm besides getting doey-eyed and bouncing a lot?
I agree that coding on a whiteboard is just silly. It's one thing if they ask you to whiteboard a system architecture, but coding on a whiteboard is like cooking with a typewriter. My solution: I bring my laptop with me. Instead of depending on the interviewer providing an environment that can demonstrate that I can code, I can just do it right in front of them.
I also try to have some sort of relevant and short presentation at the ready, but I've never needed it.
Don Howard wrote:
The author genuinely believes that the top tech companies do a good job at interviewing but it just isn't true.
How could you have arrived at that conclusion after reading this blog entry? Did you read a different post than the one I wrote? I said interviewing is a terrible mess, and 10% of all interviewers ask the same ridiculous questions to every candidate year in and year out, and I'm not a fan of interviewing the way it's practiced in our industry, on account of it being a "crapshoot", and that even good engineers can wind up not getting offers [because of the inherent randomness and poor selection power of the process most places use.]
Did that mean nothing to you? Interviewing is random! If you get a job, you're lucky! If not, I absolutely agree with you -- it's not necessarily a knock on you.
I can tell you this: at every company I've ever worked at (5? 6 total, maybe), many folks concluded that on a different day, with a different group of interviewers, they may well have failed to get an offer.
Put another way, many of us (myself included) believe that for virtually every employee Y of any sufficiently large company, you could find a group of interviewers A through F who would fail Y in a round of interviews. It's a wonder companies hire anyone at all!
but for some reason there are all these people floating around who think they know everything there is to know about software development
Well, that's because there are many documented cases of totally self-taught developers creating products that sold a zillion copies and made them into zillionaires. This isn't fiction. It's fact, and it's been going on continuously from 1970 to 2006.
I don't know of any successful brain surgeries by self-taught brain surgeons, or any successful 747 landings by completely self-taught airline pilots.
Does this mean Steve's original comparison sucks? Partially. It could mean that our current tech is so primitive that, like brain surgery in 1850, is essentially experimental patient killing.
Thus, it really doesn't matter if a "professional" or "self-taught" brain surgeon is working on you in 1850. Either way, you're gonna die.
If Steve thinks the state of software development has advanced as much as brain surgery has from 1850 to 2006, then he's a far more exuberantly optimistic man than I.
No no, brain suregery is lagging behind commpared to programming.
Have you heard about Test Driven Brain Surgery? Version Controled Brain Surgery? Agile Brain Surgery?
My point is–programming is very different from surgery, or engine repair, so comparing those is not fair.
This is not to say, that programmers may feel free to be ignorant about their subject.
One idea might be to ensure that the job reflects the interview. Some years ago I went through a very encouraging selection process, which included writing a pseudocode solution, for a job that turned out to be so depressing that it ended my twenty year love affair with programming.
I am now a freelance journalist; pays peanuts but it beats working for a company that thinks enforced technical ignorance is a good way to minimise staff turnover.
“The Harsh Reality
They're going to test you on algorithmic complexity analysis, advanced data structures, algorithm design, ...
If you're lucky, that is.”
If you are lucky they will call you on time on a day of your phone interview with them. Not more than half an hour later, that is…
If you are lucky they will even reschedule the interview for a next day if you were called an hour later and you had already left and was unable to answer their call.
If you are lucky they will apologise when they call you next day more than half an hour later than a scheduled time.
And after that they will even send you a courtesy letter saying that you were unlucky… If you are lucky, that is.
Nice post. I worked at Oracle for many years in software development. I had my favorite questions - though they tended to be more logic-driven than code or language specific.
Now I'm doing a start-up. And it's not glamorous. So I challenge the "if money is all your after" assertions in your post. If money is all your after, actually you do belong at Microsoft or Oracle or Google or Company-x-y-z. If you are insane enough to pursue your own dreams & sacrifice a steady income to do it, money is definitely not all your after...
Stevey, I have read the whole article and all your comments and my conclusion is the same as before, I love you!
Signed,
Secret Admirer
Stevey, I have read the whole article and all your comments and my conclusion is the same as before, I love you!
Signed,
Secret Admirer
Stevey, I have read the whole article and all your comments and my conclusion is the same as before, even if you use emacs and I like Vim, I love you!
Signed,
Secret Admirer
Steve, posting secret admirer comments on your own blog is pathetic; posting the same one three times? I mean, really.
My favorite interview technique, which worked surprisingly well, was to give folks a printout of four or five source files for a particular (not so well documented or organized) module, some background information, and give them half an hour to glean what they could from the code, ideally telling me at least the dependencies between the different source files, and some of the basic data structures used.
Hiya Adam!
It couldn't have been me; I don't use VIM. But perhaps that's why he/she/it accidentally posted it three times. :)
Hi Steve,
Yes, I agree with you. The whole interview thing is one big lottery.
I personally think that some of the randomness can be eliminated by making the interview longer. I've seen some people who time their interviews - its like 30 minutes and whatever gets answered in that. But preferable I'd like to have free-form (i.e. no pre-decided questions, at least not an exact number) and free-length interviews. Kinda like seeing how things go and playing along.
Maybe thats because my time is not very "precious", bottom rung software engineer that I am ...
I like the first half of the analogy you draw with airline pilots and so on. I agree that a company wants to be sure that the person they hire is qualified. However, this is only one side of the problem. The other side is where this analogy fall apart. For example, I have passed my driving test, and I've been driving for years, but I am not qualified to test other drivers.
What we have is interviewers, unqualified in testing, attempting to test applicants with untested questions and often looking for a subjective answer heavily coloured by personal preference. We tend to ask technical questions about our pet subjects and tend to hire applicants that know and agree with our opinions (this is the cloning trap.) But if we don't ask technical questions how do we assess applicants?
Interviews have two players and each has a different goal. The candidate's goal is to find a compatible work environment. The interviewer's goal is to find a qualified employee. To win, both need to achieve their goals: it's a collaborative game. Any process applied to an interview as either interviewer or interviewee must move us towards our goal, but must not block the other player from achieving theirs.
Here is an approach, for what it's worth. It still requires applicants to express technical knowledge but doesn't fall foul of the cloning trap. Rather than ask about a technical subject I know well, I ask candidates to talk about a technical subject they know well. Whether or not I know the area well, I look it up after the interview to assess how well the candidate was able to describe the subject to me.
I can do the same in writing, by asking candidates to bring code samples. I can also do it in code, by asking candidates to bring demos. It gives me a clear picture of candidates abilities without inadvertently presenting the company as rigid or bureaucratic.
Hello Steve,
I came across your blog accidentally, and simply love reading it. Making no bones about the fact that I was a terrible programmer (a student currently) - Its mainly helped me to figure out ways I can improve (on the interviewing candidate's side).
I am richer,mentally, for having read your blogs. Great work!
-Mallika Iyer
Hi,
I mean the candidate being interviewed .
Rhialto, as a novice computer scientist I think the best lesson I've gotten so far out of it is that if one approach doesn't work, try another. Because with software, generally, when one approach isn't working, its not because of the language's features.
I think this applies to the real world, as well.
If getting a job at Microsoft doesn't work out, instead of complaining, find a different company. Or get better and try again.
<< Home