January 22, 2008
The job market for software developers is hot. This is great news for programmers, but it makes the interview process challenging for potential employers. A reader recently wrote me expressing some concern about the interview process:
You mention Vertigo requiring a code sample, then a phone screening, then a hands-on test in the face-to-face. We have a very similar process, but somehow a large percentage of the candidates who make it to the hands-on test are very poor and should have been eliminated at step 1 or 2. The signal to noise ratio is terrible. It costs a great deal to spend so much time doing face-to-face interviews with people who often should not be developers in the first place. I am curious how much light you might be able to shed on the specifics of your requirements on candidates. What part of the process is the most effective in separating the cream, how and why?
It is very expensive to get the phone screen wrong-- a giant waste of time for everyone involved.
The best phone screen article you'll ever find is Steve Yegge's Five Essential Phone-Screen Questions, another gift to us from Steve's stint at Amazon.
Steve starts by noting two critical mistakes that phone screeners should do their best to avoid:
- Don't let the candidate drive the interview. The interviewer should do most of the talking, guiding the conversation along until they're satisfied the candidate knows the answers to the questions (or has given up).
- Watch out for one-trick ponies. Candidates who only know one particular language or programming environment, and protest complete ignorance of everything else, are a giant red warning flag.
The point of the phone screen is not for the candidate to drone on about what they've done. The interviewer should push them out of their comfort zone a bit and ask them related questions about things they haven't seen or done before. Ideally, you want to know how this person will react when they face something new, such as your codebase.
In an effort to make life simpler for phone screeners, I've put together this list of Five Essential Questions that you need to ask during an SDE screen. They won't guarantee that your candidate will be great, but they will help eliminate a huge number of candidates who are slipping through our process today.
1) Coding. The candidate has to write some simple code, with correct syntax, in C, C++, or Java.
2) OO design. The candidate has to define basic OO concepts, and come up with classes to model a simple problem.
3) Scripting and regexes. The candidate has to describe how to find the phone numbers in 50,000 HTML pages.
4) Data structures. The candidate has to demonstrate basic knowledge of the most common data structures.
5) Bits and bytes. The candidate has to answer simple questions about bits, bytes, and binary numbers.
Please understand: what I'm looking for here is a total vacuum in one of these areas. It's OK if they struggle a little and then figure it out. It's OK if they need some minor hints or prompting. I don't mind if they're rusty or slow. What you're looking for is candidates who are utterly clueless, or horribly confused, about the area in question.
Of course, you'll want to modify this process to reflect the realities at your shop-- so I encourage you to read the entire article. But Steve does provide some examples to get you started:
Write a function to reverse a string.
Write function to compute Nth fibonacci number.
Print out the grade-school multiplication table up to 12x12.
Write a function that sums up integers from a text file, one int per line.
Write function to print the odd numbers from 1 to 99.
Find the largest int value in an int array.
Format an RGB value (three 1-byte numbers) as a 6-digit hexadecimal string.
Good candidates for the coding problem are verifiably simple, with basic loops or recursion and perhaps a little formatted output or file I/O. All we want to know is whether they really do know how to program or not. Steve's article predates it, but I'd be remiss if I didn't mention Why Can't Programmers.. Program? here. The FizzBuzz problem is quite similar, and it's shocking how often interviewees can't do it. It's a bit hard to comprehend, like a potential truck driver somehow not being able to find the gas pedal or shift gears.
Design a deck of cards that can be used for different card game applications.
Model the Animal kingdom as a class system, for use in a Virtual Zoo program.
Create a class design to represent a filesystem.
Design an OO representation to model HTML.
We're not saying anything about the pros and cons of OO design here, nor are we asking for a comprehensive, low-level OO design. These questions are here to determine whether candidates are familiar with the basic principles of OO, and more importantly, whether the candidate can produce a reasonable-sounding OO solution. We're looking for understanding of the basic principles, as described in the Monopoly Interview.
Scripting and Regular Expressions
Last year my team had to remove all the phone numbers from 50,000 Amazon web page templates, since many of the numbers were no longer in service, and we also wanted to route all customer contacts through a single page.
Let's say you're on my team, and we have to identify the pages having probable U.S. phone numbers in them. To simplify the problem slightly, assume we have 50,000 HTML files in a Unix directory tree, under a directory called "/website". We have 2 days to get a list of file paths to the editorial staff. You need to give me a list of the .html files in this directory tree that appear to contain phone numbers in the following two formats: (xxx) xxx-xxxx and xxx-xxx-xxxx.
How would you solve this problem? Keep in mind our team is on a short (2-day) timeline.
This is an interesting one. Steve says 25% to 35% of all software development engineer candidates cannot solve this problem at all-- even with lots of hints and given the entire interview hour. What we're looking for is a general reluctance to reinvent the wheel, and some familiarity with scripting languages and regular expressions. To me, this question indicates whether a developer will spend days doing programming work that he or she could have neatly avoided with, perhaps, a quick web search and some existing code that's already out there.
What are some really common data structures, e.g. in
When would you use a linked list vs. a vector?
Can you implement a Map with a tree? What about with a list?
How do you print out the nodes of a tree in level-order (i.e. first level, then 2nd level, then 3rd level, etc.)
What's the worst-case insertion performance of a hashtable? Of a binary tree?
What are some options for implementing a priority queue?
A candidate should be able to demonstrate a basic understanding of the most common data structures. More specifically, the big ones like arrays, vectors, linked lists, hashtables, trees, and graphs. They should also know the fundamentals of "big-O" algorithmic complexity: constant, logarithmic, linear, polynomial, exponential, and factorial. If they can't, that's a huge warning flag.
Bits and Bytes
Tell me how to test whether the high-order bit is set in a byte.
Write a function to count all the bits in an int value; e.g. the function with the signature
int countBits(int x)
Describe a function that takes an int value, and returns true if the bit pattern of that int value is the same if you reverse it (i.e. it's a palindrome); i.e.
boolean isPalindrome(int x)
As Steve says, "Computers don't have ten fingers, they have one. So people need to know this stuff." You shouldn't be treated to an uncomfortable silence after asking a candidate what 2^16 is; it's a special number. They should know it. Similarly, they should know the fundamentals of AND, OR, NOT and XOR-- and how a bitwise AND differs from a logical AND. You might even ask about signed vs. unsigned, and why bit-shifting operations might be important. They should be able to explain why the old programmer's joke, "why do programmers think Oct 31 and Dec 25 are the same day?" is funny.
Performing a thorough, detailed phone screen is a lot of work. But it's worth it. Every candidate eliminated through the phone screen saves at least 8 man-hours of time that would have been wasted by everyone in a hands-on test. Each time an unqualified candidate makes it to the hands-on test, you should be asking yourself-- how could we have eliminated this candidate in the phone screen?
Posted by Jeff Atwood
"...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.
my $filename = $_;
my @data = $filename;
# Loop once through with simple search
# None found, strip html
$text = ;
$text .= $_ while(@data);
$text =~ s#[^]+##gxs;
# Strip line breaks
$text =~ s#\n|\r##gxs;
# Check for occurrence.
if($text =~ /\(?(\d\d\d)\)?[ -]?(\d\d\d)-?(\d\d\d\d)/)
# Print out result
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.
1) 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.
2) 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.
3) 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.
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.
Steve - it may need to be inside a class to be a method, but the question does not state a requirement to define the entire class. What Jon wrote is a perfectly valid method signature to stick inside any class (although it probably ought to be static). So actually, yes, he has "written a method", and you're just being a wise-ass.
Save those antics for TheDailyWTF.
These are good questions - so long as the interviewer is REALLY just looking for thought process. It doesn't matter that the candidate knows about grep, it matters that the candidate asks about the tools or environment.
When I interview I tell the candidates to have google ready and I give them a moment to try to google things. To me, it shows more about the candidates' ability if they can come up with a solution having never seen the facts than one who had the solution memorized.
First of all, I don't like this inquisition style of interviews.
I'm doing interviews on a very regular basis.
And for me it's pretty simple.
Junior - all I want to know is:
a) can you say "I don't know ... help me"?
the same as junior + "Yes. I'm able to understand partial problems and write specification for them"
I can do the rest
...I don't care what people can or can't remember. All I want to know is how they think, what are the reactions on unpredictable situations and whether they can work in team.
What's so important on writing huge regexes from scratch ... or finding bugs in printed code?
Most of the things you said on this article are correct. But the most important thing is that "Duh-ness" of the interviewer. Recently at an interview, I was asked "I have an insanely huge log that contains IP and timestamp of all the people who logged in to my site, I want to find the first one who never returned". I gave answer 'A' which was doing o(n) using HashMap. The interviewer wanted answer 'B' which was doing o(n) using BitMap array. I was rejected because I did not give exact answer that the interviewer knew.
Also, I was asked a question "Would you write multi-threaded programs on a single-processor system ? " - The question itself is wrong and shows the level of the interviewer. I said so to the interviewer who had a fake US accent.
Needless to say that I was rejected both the times.
Everyone that says this blog is a joke should think twice before rejecting it... The blog could be very useful for a certain type of role you're hiring for.
I use almost 1:1 the same sequence in my interviews. If you're a developer for an embedded system, low level stuff, the number 32768 should ring a bell. If not, OK, next question. Knowing that a C string has trouble, a strlen in a loop might be slow, etc. Bitshifting (why?), optimizing, code reading/explaining in an interview, it all makes sense.
Of course, the willingness to grow is fine, but not for 40 yo programmers. Come on, don't tell me you forgot how to to resolve a circular dependency in class definitions.
Somehow developers should not me coding monkeys, they should know how to approach a problem on a per situation basis. That's why scripting, knowing bits and bytes, graph theory, it couls all come together.
People have laughed me in the face: haha, a string reversion quaestion, duh. And then he f*cked up the answers, the 8 lines of code was buggy and badly explained. Yeah, I did C# recently. As if you would ever forget to code in C/++...
Thanks for supporting me thinking I do great interviews :-)
PS the truth is always in the explanation... Why do you think this is faster? Why would you ++i instead of i++? Why is code size not important? How to maintain this code? Why...