“…are you hiring me to wrote code…”
Just hope they aren’t hired you to teaching an English class.
Being indignant works better if you can put together an intelligent sentence slick…
I also have an interview coming up and I studied these questions, most of which were very easy (phew). I appreciate you posting this up for those of us who don’t have 20 years of experience (or a lead pipe). Any intel on what employers may be looking for is extremely valuable information. Keep up the good posts!
Great post Jeff. It took me more than an half an hour to read all comments.
I did like it for my job interview.Before I don't understand the screen interview.It is mean for my IT professional or technological in Interviews.
I did like it for my job interview.Before I don't understand the screen interview.It is mean for my IT professional or technological in Interviews.
I certainly understand where the idea comes from in regard to this line of questioning for an interview, but I belong to another school of thought entirely in regard to “getting it done” as a programmer. I’ve been programming since I was 12, I would be some what annoyed by that line of questioning and not be interested at all in working for people who thought being so linear was so important.
The mindset revealed by your questions is that only linear thinkers matter, those who are centered around facts are more valuable than those who are focused on process. The questions reminded me of the busy work they gave me in grammar school, just to hammer in multiplication tables, repeat, repeat, etc.
I would never waste my brain cells memorizing all that stuff, it’s dumb really, if I needed it I’d look it up, if not I’d keep it out of mind as it should be. Of course, all the linear thinkers love that stuff and they assign a belittled lable to those who don’t belong to their club, the posts from that school of thought takes on a snobbish allure here. I understand why they think it’s important and it’s a self fulfilling vicious cycle that other members of the linear thinkers club only want to hire and value other members. It’s also the flaw of being a linear thinker, you don’t understand any other way of thinking.
That’s not to say knowing this stuff isn’t valuable, it is to a particular type of thinker. The problem is that those type of thinkers are stuck thinking in a linear, one size fits all manner - thus the trap this sort of thinking creates. The problem with programming companies and IT in general is the over abundance of this one line way of looking at things.
Someone who doesn’t approach problems in this fashion is not “dumb” or unvaliable to a company and yes even as a programmer. Programming is about solving problems, how someone approaches problems when they really are problems is what makes a good programmer. The flaw with these type of busy work questions is that a programmer doesn’t create needless problems for themselves, they avoid them. When a needful solution is prevented by a real problem that can’t be avoided, then that’s when a programmer’s skill jump into action and finds the best short cut possible.
One does that by understanding the fundementals and using whatever means necessary to solve problems within the context they arise.
Being a spherical thinker and not a linear one, when I don’t need to be that is, I get why certain people would put out this kind of litmus test out there, but the flaw is that not everyone thinks like that and being a linear thinker would limit you to thinking that yes they do. Someone, like myself, wouldn’t be interested in doing a bunch of busy work for someone trying to se how many hoops I’d jump throw to prove to them how badly I wanted to work for them. I’d see the interviewer as flawed in his approach and limited in their concept of what makes a good programmer. The flaw is that this line of reasoning is so limited in scope.
Now of course the linears would brand me “not worthy” and would never question that their questions were off not me, but that’s what the limits of being a linear thinker consists of.
I’ve intereviewed for these kinds of jobs and this kind of mindset has come up almost always, and I’ve never wanted to work for any of them because of how they approach things. I’ve found out that my best bet as a programmer is working for myself because these IT companies just don’t “get it” when it comes to solving problems. Now that might sound like sour grapes but there’s a reason IT companies are always “looking for people”. If they’d stop hiring people who waste their time knowing things that don’t really matter and were more process oriented problem solvers, they’d get people who had broader forms of thinking. that would translate into better solutions and not just a code monkey’s code monkey with a code monkey stamp of approval.
That guy’s post, chaching, was actually right on - he said it in a brusque fashion, but I thought he was being humorous whihc was in sharp contrast to the stodgy approach presented in the post. He was right, someone who ws that “stuck” on factoids needs a figurative lead pipe to the head, as to say a reality check. The approach in the psot was someoting out of some geek wish list, someone who lives in a vacuum seeking validation by evaluating others on linear thining prowess, as if that was all that mattered or was the only way to approach problems. It’s funny how the linears took such offense to chaching’s post, again they can only see things one way - that’s the problem with having problem solvers that all linear thinkers. Yes, their focused thought process gives them on edge as far as mental reach - into the depths were others wouldn’t bother. But what linears fail to realize, because they are linears, is that they gain that edge at the cost of breath. Haivng great depth and limited breath is a liablity in many circumstances, especially as a problem solver. Again programmers are problems solvers not code monkeys just creating code for the sheer joy of creating code. A problem solver dedicates their brain cells to what they need to know at any given moment, the right code at the right time is a tool to get to a solution. Showing off how much code you can rattle off from the top of your head in spontaneous spurts over the course of a phone interview is the sort of bragging rights a linear thinker would deem important. I understand linear thinking and thinkers so I get that, what tells you something is that it doesn’t work that way the other way around and that is the fundemental flaw of linear approaches to things.
@Raf: Well I guess I must be “linear” then, because they all sound like perfectly reasonable questions to me.
If you are hiring a software developer then what exactly is wrong with asking them to develop some software?
Regardless of whether they think linearly, spherically or in hypercubes I would still expect them to be able to outline a quick solution to “Print out the grade-school multiplication table up to 12x12.”, do some OO design and describe the properties of a data structure. That is after all, the sort of tasks involved in the job they are applying for. They seem entirely relevant to me.
But I’ll bite: What questions would you ask a “spherical thinker” then?
If I’m asked these questions in an hour long phone screen, then I take it as weeding out the idiots and answer them. Got some similar ones in the phone screen for the job I have now, and let me tell you, the day to day stuff here is as interesting as any of you could imagine.
However, if I got them in the day long real interview? I’d be looking really carefully at exactly what they’d expect me to be doing. A job I was happy to be turned down for asked for the parameter list for a particular Java Swing widget - now, I used to work for Javasoft, but even when I was in the middle of implementing Mac Swing I could not have done that off the top of my head; that’s what code completion is for.
XX)
#!/usr/bin/perl
while(*.html)
{
my $filename = $_;
my @data = $filename;
while(@data)
{
if(/(?(\d\d\d))?[ -]?(\d\d\d)-?(\d\d\d\d)/)
{
push (@files,$filename);
next;
}
}
$text = ;
$text .= $_ while(@data);
$text =~ s#[^]+##gxs;
$text =~ s#\n|\r##gxs;
if($text =~ /(?(\d\d\d))?[ -]?(\d\d\d)-?(\d\d\d\d)/)
{
push (@files,$filename);
next;
}
}
print join(’\n’,@files);
There you go, finds phone numbers in that format, even from between html (if it’s proper, ofc) and through line breaks. Coding time: 5-10 minutes. Sure, there’s a lot of code out there to do that, but you really want just a random unix geek who can do perl/python.
Still, I’m guessing management would freak out There’s no way you got that out in less than an hour, do it again in some other way we can understand. sigh
It amazes me that so many people think that any of Jeff’s questions are esoteric. I don’t expect a candidate to have depth in all those areas, but they should know a little bit about them. We’ve used similar technical interview questions and have had excellent results in our hiring process.
I’d probably never apply at a company with such ridiculous criteria.
The code samples are utterly meaningless. Fibonacci sequence? C’mon. What indication will that possibly have of a candidate’s ability to enter into an actual large-scale (or even small-scale). Very few programming jobs actually involve purely algorithmic solutions, mostly they involve understanding system architecture and library interfacing.
Phone screening. Fine with that. But remember it’s a two-way street. If I’m applying for a job, I’m also screening the employer. Asking me to implement a silly textbook algorithm is a sure-fire way to get me to move on to someone who actually knows what they want.
Hands-on test face-to-face. I’m not quite sure what this exactly entails, but if it’s what it sounds like, you’ll certainly screen yourself out of a lot of good programmers this way. Personally I cannot think properly with someone staring over my shoulder. Secondly, as someone else mentioned, Google is your friend. Any sufficiently non-trivial task (otherwise known as any task worth testing on) should require some research (a very important part of any programmer’s job - and one that many people fail at).
Seriously, with this type of screening process, I expect what you’ll get is people who are good at taking tests (i.e. fresh college grads) and filter out people who have actually worked on large-scale software systems (but have long forgotten how to implement something like the Sieve of Eratosthenes because it simply never comes up in real programming work).
If all you’re screening is fresh-faced kids, this process might help to some degree (you’ll at least see who was paying attention in class). If you’re screening veterans with a decade or two of programming experience this process is fairly worthless and worse, insulting to the applicant. If insulting the applicant isn’t a major concern for you, then all I can say is you deserve what you get.
I’d like to add that I think it’s important to have a mix of mentalities in any shop. In general you’ll find that people who take a large view of software (i.e. from an engineering/architectural perspective) tend to not be the best at detail-oriented or drudge work (e.g. user interface code). On the other side, code-monkeys (as they are so affectionately known) churn out this stuff like it’s high-school poetry but tend to create unmaintainable messes if they are allowed to architect an entire system.
Personally I’m the architectural type and know my weaknesses. I can help your average code-monkey turn 100 lines of code into 10 but have little interest in doing his job (even though, on paper, I’m more qualified). If you hire a bunch of people like me, your software will be beautiful under the hood, but look like crap from the outside. If you hire a bunch of code-monkeys, you’ll have a flashy interface built on a code base that’s unmaintainable. You need both types, and your screening/hiring process needs to reflect this.
The fundamental problem with creating formal processes for dealing with the vagaries of human thinking and behaviour is common across many fields: they tend to be too rigid and too narrow, and worst of all, usually become a substitute for actual thinking and responsibility for decisions. Guidelines are always helpful for helping us organize our thoughts, but if you aren’t willing to step outside those guidelines and take personal responsibility for doing so, then I’d suggest you first hire (or promote) someone who is.
I’m not convinced that these questions tell me much about an applicant’s ability to develop an actual application people might use. Trivia about bits and bytes or data structures might be important in Yegge’s line of work, but it’s pretty low on the list if I was hiring someone to develop web applications (for example). Of course, web applications development is an example here; the questions should be tailored towards your line of work.
But performance on Yegge’s questions don’t tell me anything about how a developer would do in just about any real-life programming job. High order bit? Really? Does that factor into the way Amazon developers work, in this day and age?
I won’t say I aced the whole 5 questions, but I did the FizzBuzz in a couple of minutes. I’m not entirely happy with my solution yet. I want it to need one less if. Strangely, when I wrote it out on paper I did it with Java-like for loops and logic even though I haven’t used them really since university. Perl for the win.
To all the haters, this is a phone screen. The whole hiring process is two-way, if you don’t like the way the company hires people you may not want to work there. Plus, it’s the type of thing Steve Yegge says he wants to see. Presumably he has learned this from experience and different interviewers may look for different things. Probably most of the time most programmers don’t have to care about the limitations of integers nowadays, but if you have no regard at all and you need your application to really scale really big, then you had better find out quickly. Though I might just brush up on my twos complement, haven’t done that in over 10 years I think.
Someone said they failed at a couple interviews, but aced a couple of later ones and the later success was down to study and interview technique, not so much skill. Studying and wanting to learn is a skill. I haven’t really had to learn too much outside my immediate field of work and I’m having trouble making myself learn more.
I’m genuinely surprised at all of the defensiveness here.
To the people saying that most programmers only have to write a couple of reports and a couple of forms: you don’t need a programmer for that, just somebody with marginal Microsoft Access experience.
To the people saying that you could get the answers on Google: sure you could, but if you have to look up the word “the” in the dictionary in order to obtain the correct spelling, you’re not going to make it as a writer. There are some fundamental things that you just HAVE to know if you’re going to be working on shrinkwrap software or a mission-critical business system.
To the people saying that they’ve been successful in their careers in spite of not knowing these things: so what? Wealth and profits prove very little about actual skill and quality. Verizon and Bell make billions per year in profits. So does McDonald’s.
If your idea of programming is to look up everything on Google, then you’re a prime candidate for outsourcing. That’s exactly what so many of the outsourced developers do: skim the first page of Google results, and if they don’t get an obvious answer there, start spamming forums with inane questions. If this is your strategy and you’re managing to make more money than they do, consider yourself extremely lucky. If you lack the ability to come up with original solutions, then you deserve to be a low-paid code monkey.
And if you have seriously never had to use a regex, a tree, a hash table, a bitwise AND, a string formatting function, a queue, or even a 2-level class hierarchy, and you’re absolutely 100% sure that these things would never have come in handy, then please, for your own sake, find a new job, because your current one is turning your brain into putty.
If I weren’t so sure that it would weed out ALL candidates, I’d throw a basic multi-threading question in there as well. How many non-trivial products today are single-threaded? Even web apps aren’t immune; you have to know how to avoid long blocking calls on the server side.
A lot of people seem to think that perfect answers are needed to all these questions; note that this is a first-stage phone screen, just to decide whether or not to bring you in for interview.
So, “I think my text editor can do a recursive search for a string matching a pattern” is good enough for the regexes question (unless you claim knowledge of something like Perl on your CV); it shows that you are aware that there are tools to do the job quickly, even if you’d have to find them.
Remember that the goal is to remove the obvious losers before you bring them into the interview room, so perfect answers aren’t needed. You want answers that show that the candidate is aware of the big world of computing, and that they are capable of escaping their box if they need to. Indeed, I’d be suspicious of anyone who could give me perfect answers to all 5 questions without stumbling or having to tell me what they’d research.
I’ve been on both sides of the fence, the quiz taker and the quiz maker.
As a quiz taker, the worst was a twenty question test on a “made up” programming language. The company required 19 out of 20 correct. I got 18, which wasn’t enough to move on the next phase, and they didn’t validate my parking either (bastards). The person who set me up on the interview said that the company did a lot with SQL, so naturally I studied SQL (silly me) before the test. Didn’t help one bit.
As a quiz maker, we were interviewing for C# candidates, so I made up a little 10 question quiz. The questions were not that hard and I asked the candidates after the quiz, do you think the quiz was fair, was it too hard, too easy, that sort of thing. Most of them said it was fair and good test of basic knowledge. Basically, we wanted some programmers with some C# experience, who would be getting into a large C# codebase right away, not people with no C# experience, which would hurt the project.
The last question on the test was:
Write a method that adds 2 numbers and returns the result.
Usually I got something like this:
public AddNumber(int a, int b)
{
return a + b;
}
Question 10 was usually followed up with:
Do you think this method needs error handling?
What happens if I send in Int.MaxValue for parameters a and b?
And so forth. These were my probing questions.
After some probing, my final question was, how would you add 2 numbers together regardless of size?
Sometimes I got blank stares, other times I got solution proposals and so forth. But that question usually revealed alot about the candidate, and how they would go about solving a problem.
The truth is no quiz is perfect, I used quizzes as a validation that the candidate knew something about C#. They weren’t the only thing we looked at. We had several candidates that did well on the quiz that we didn’t hire. For the quiz, I tried to keep the questions from having to memorize anything or any “smarty pants” questions. But, I admit, this was tough to do. Quizzes in of themselves tend to put a superiorty complex on the quiz maker and an inferiority complex on the quiz taker.
There so much stuff out there, its impossible to know everything, so yes Google is your friend to get your started. I haven’t worked on a Unix box in over 15 years, so Grep is beyond my sphere of infuence. But, hopefully the job description says something like “Solid background in Unix”, in that case I would screen myself from the job by NOT submitting a resume. But most resume and job searches blast resumes as long as there is a keyword match.
Self correction… on previous post
public AddNumber(int a, int b)
{
return a + b;
}
public int AddNumber(int a, int b)
{
return a + b;
}
Phone interviews aren’t supposed to replicate the process of sitting down and solving a problem. They’re supposed to weed out the people who lack the basic fundamental skills to sit down and solve any of the important problems that your business encounters. Same goes for in-person interviews; they aren’t going to immediately identify the vigorous go-getters, they’re just going to eliminate the ones who are downright unpleasant.
As a Psych major, David, I’m sure you’re familiar with Bloom’s Taxonomy. If someone can’t even demonstrate basic knowledge or comprehension of a subject, they won’t be able to apply it at any job. Obviously - people can’t apply knowledge that they don’t have, can they?
Why is this so complicated? If you can’t solve a simple problem, it’s extremely unlikely that you’d be able to solve a complex one. You can’t get through differential calculus if you don’t know how to take a derivative. You won’t make it as a statistician if you can’t calculate a binomial coefficient. You can’t write novels if your vocabulary is limited to 100 words, even if you’ve got a dictionary and a thesaurus right beside you. And indeed - you can’t write a complex program if you don’t know how to use a hash table, traverse a tree, or model a couple of animals and verbs as a class a hierarchy.
I truly hope that the people who consider these to questions to be “academic”, “egghead”, “brain teasers”, etc., aren’t actively employed as programmers or software engineers. The only thing worse than ignorance in this industry is militant ignorance.
Oh, and to say that interviews are the worst predictors of performance seems a bit specious, given that they’re the only predictors available and are therefore also the best.
Google hires by the Lake Wobegon strategy (everyone they hire is above average). They are trying not to dilute the quality of their engineering pool over time.
http://googleresearch.blogspot.com/2006/03/hiring-lake-wobegon-strategy.html
Steve’s questions from his Amazon screening days are designed to find people who are curious, curious enough to have gone all the way up and all the way down the abstraction ladder in computer science. If you aren’t interested, are you interesting?
Also, look at where he’s coming from. He’s a productive Emacs and Unix hacker with some classic tools in his toolbox. He’s trying to avoid people who would be profound time-wasters.
The interview questions are from the cutting-edge, research-oriented places with problems no one has ever solved before. There’s no way to Google answers to them, and if you don’t have the solid CS background to invent the answers, you won’t be able to make yourself useful.
By the same token, if you’re not trying to get a job at that kind of place, if you’re not interested in the hacker culture or working with the best in the world, then you probably shouldn’t worry about these kinds of questions.
And finally, for those who can’t do these problems easily: even if they look stupid to you, the subjects they cover would likely broaden you as a programmer and increase your productivity.
Tim: It’s certainly unprofessional to insist on an on-the-spot phone interview. I would expect most employers to allow candidates to schedule one within some reasonable time frame (and of course during normal business hours).
David: Funny, but I would have thought that a well-chosen and carefully-tailored subset of these softball questions would be an aptitude test. Or are you talking about something like the SAT, which no self-respecting developer would ever take just to land a boring job at BoringCom writing boring business software boringly?
You certainly haven’t described your magical aptitude test in any reasonable detail. It seems like more of a roundabout way of saying that it’s all subjective, which sounds like more defensive posturing to me. The only two things you mention either have hardly any bearing on programming ability (everybody should have basic math skills), or aren’t even testable in a generic sense (“problem solving” doesn’t exist in a vacuum, it exists for specific problems in specific domains, and that’s exactly what we’re proposing to test with these kinds of interview questions).
Nervousness isn’t an excuse either. The real world is a stressful place, with unrealistic budgets and deadlines, conflicting and constantly shifting priorities, and a dozen people knocking at your door wanting their pet project done RIGHT NOW. If you can handle all that without losing concentration, you can definitely handle the interview; it’s the reverse that’s not always true, and that’s why you have an in-person interview after the phone interview and usually some kind of probationary period after that.
My advice to you is stop referring to these as “random technical questions”. All it does is reveal the underlying ignorance and bitterness. I don’t even have a CS or CE degree - I’m an electrical engineer with far less than 20 years of industry experience, and these questions are just dead easy. I’m almost embarrassed to ask questions like this to people who claim to have been working in the industry much longer than I have, because I feel like I’m insulting their intelligence by suggesting that they might not know the answer. But the fact is, so many of them don’t, and they’ve managed to blow through their entire career as a remora.
Oh, poor you, you flubbed an interview because you were nervous. That’s life, man. Time to build up your confidence and come prepared next time.