What percentage of your job interview candidates pass FizzBuzz style questions? Any tips to improve the signal to noise ratio?
At a previous company where, for cultural reasons, lack of programming skill was not a barrier to being hired as a software engineer, approximately half of our software engineers could FizzBuzz. Of our outsourced coders, I'd put the number at one of the twenty I knew, and he would need extensive coaching to make it happen.
Some of these folks were at least moderately productive at tasks which you and I do every day which theoretically happen in an IDE but do not require much abstract thinking, such as changing labels on UI elements, adding new columns to tables (by copy/pasting a line which worked and tweaking it until output matched expectations), and the like.
As I remember fizzbuzz (print numbers 1 thru x, then fizz if divisible by 3, buzz if divisible by 5, fizzbuzz if divisible by both)
I did it in a text editor in under a minute. Got two errors because I did it without thinking, fixed it, and had a working solution in 90 seconds. It's taking me longer to write this response.
I can't imagine anyone who writes code daily who couldn't get this right in under 5 minutes given a text editor and a way to run the code, but I could imagine plenty of people who trying to do it on a sheet of paper who would make goofs. And most of those would make good employees.
Yes there are people who apply for programming jobs and do not write code daily, or even cannot code at all. FizzBuzz is designed to quickly identify them and filter them out.
These sorts of tests are low pass filters, they're not designed to find good or great programmers, just confirm that the person can program at all (as we define it). Since most people who call themselves programmers really aren't, they're highly useful. Anyone who's looking for perfection of this nature in an interview and who fails a candidate for lacking that is doing the latter a favor by not hiring them.
But, to their advantage, they can select any language that they want.
Actual code that works (and running it from a terminal), we are seeing only about 15% tops maybe lower.
We have started sending a fizzbuzz-ish question, a relatively easy css question, and a word-problem about performance as pre-interview questions through recruiters. This has dropped our resume inflow dramatically and saved a lot of time, but that's depressing in a way.
We are looking for a Rails or PHP dev in waltham (near boston) currently without a lot of luck. The job has a lot of pros, but probably doesn't do itself justice on-paper.
Keep in mind that you may be getting a lot of good people with a lot of pros, but that don't do themselves justice on paper.
Are you attending local PHP and Ruby/Rails meetups and user groups? If none are available, consider starting one.
Would you be able to share that? Simple programming/algorithm questions are a dime a dozen, but I'm curious what a word probably that's appropriate to coders would look like.
Describe how you might approach researching, diagnosing, and reducing the page load time for a web page with poor performance.
Since then I've been able to interview others and I look for different things than FizzBuzz compliance. I want to see how they solve problems in general. I want to see if they have any passion for what they do. I want to see things they've developed.
I dabble in code, but am no where near the level I would have to be to do any job in this area, I mean seriously. Took my two minutes to do it with a pen and paper in PHP, same with in JS, same in bash scripting.
How can anyone who isn't able to do this pretend to even have an interest, yet alone the ability to do the job?
There are people with degrees in Computer Science who can't pass FizzBuzz. They think they aren't very good at programming, but think that the company will train them. There are all kinds of reasons why people who can't FizzBuzz apply for programming jobs.
Heck, look at how much cargo cult programming goes on at companies from top to bottom. PG pointed out that one of the main reasons for dot.bomb failure was not being able to technically execute (sure, the company may still have been hopeless, but they didn't even get to test their sales proposition).
And a lot if not most companies simply don't focus on technical excellence or even simple competance. E.g. look at how the powers that be at Friendser let it wither on the vine because they assumes the tech was in the bag while their persued big deals, all the while ignoring for years (I think) that the system had gotten so overloaded it was essentially useless.
And, heck, if I had the time to mentor you and you were interested, I might take you on even at your current level. You "know your own limitations" today, but you're still, say, better than 70% plus or minus of the people who call themselves programmers. If you can execute the little stuff, I can teach you the big picture (with the aid of a book or two and some hard work).
I would love to say that you can tell from a CV whether or not they could pass FizzBuzz, but it's not true. I've interviewed MScs and PhDs that could not do FizzBuzz. Seriously.
The phone screener is your friend.
It's harder than it sounds, but I also don't expect a perfect answer - generally I just want to see how people think out of thee box to try and solve an odd problem.
if job requires "Hibernate" and I've used hibernate in my previous job, but have never configured it from scratch, only tweaked some models, wrote some EJBQL queries - does this count as "knowing Hibernate"? I've also never used Hibernate annotations, becasue we use hbm files, and we have templates to make the, so I'd have problems writing such file from scratch.
Do you check knowledge of required libraries on the blackboard? Do you assume people should know all the corners of such libraries, or do knowing some things and wanting to learn more if it will be needed suffices?
I use at work jboss, hibernate, jbpm, and many other technologies that are often mentioned in job offers, but I don't feel I can say I know them - only the parts that I needed to do the job. Is this considered not enough?
The more of the description you can match the better it is, but 60-70% will get you an interview in most places.
On average it takes people around 5 minutes to do.
We have people do it on a whiteboard to get them standing up and moving.
Edit: For example, iterate through this string every time you hit an 's' print fizz etc...
We get about half our interviewees unable to solve problems that are similar or easier during interview. Whether that's nerves/stress or simply an indication that they got someone else to do the homework for them we don't know.
One candidate even phoned a friend during the coding part of the interview to get some answers. For some jobs he'd be hired, but not for most.
I attribute this to two things, first I think our phone screenings work well enough to keep out people who really can't do FizzBuzz, and second that I'm fairly generous during interviews. I often don't expect real code, sometimes I'm satisfied with just a discussion of the algorithm (no white board coding at all). I don't expect code to compile and I even let candidates use undefined "helper" functions (although I usually only allow that if I get the feeling that they could implement them if asked).
* For those that are curious I have two favorite questions - print out all the permutations of a given (ASCII) string and describe a search algorithm for a sorted array that has been split in two and the two pieces have been swapped (i.e. - 4,5,6,7,8,1,2,3).
Let's say I interviewed you. I had asked to implement the fastest algorithm to give back the largest palindrome of words in English dictionary and compare it the largest palindrome of the french language. What the best solution you can come up with in 45 minutes.
After, that I asked you, write a simple ftp server, in the language of your choice. With your first solution, I asked you implement a SSL library and add it to the ftp server to make it sftp.
Based on that I can judge how good of a programmer you really are.
Sorry for being sarcastic, but I think most interviewers are on a power trip. They ask questions that if they heard for the first time, they couldn't come up with answers either.
I think your better off really talking about and going in depth with the programmers experience. If your experienced yourself, you should have no problem.
His second is trickier, but solvable. And, no, I've never seen that (particular) question before.
It could be the person studied up on all sorts of puzzles and famous algorithms online but hasn't really written or programmed anything.
Not all jobs require that much expertise. You could be doing some really simple programming work.
I think most interviewers ask these type of questions 1.) make themselves feel smart 2.) they get a kick out it
There is an obvious recursive algorithm, but I'd be worried that if I gave that the interviewer would quibble about stack usage (although it is going to be linear in the number of items being permuted which should be OK most of the time).
Thinking a bit more, I can see that it should be possible to do an iterative algorithm that needs little or no state other than the last permutation generated and that given a sorted input string would generate the permutations in lexicographic order. The basic idea is that if you partition the string into two parts, AB, such that no permutation of B exists that is lexicographically after B, then the next permutation of AB is formed by replacing B with the lexicographically first permutation of B, and then exchanging the last character of A with the first character of the new B. (I think that will generate them all, in order--but I've not seriously analyzed it--I'm just riffing off the top of my head as I type here, like I'd be doing in an interview).
OK, now I'd worry about that step of replacing B with the lexicographically first permutation of B. That can be done by sorting B, but then the interviewer might complain about all that sorting. Aha! The lexicographically last permutation of B and the first permutation or reverses of each other, and reversal can be done in O(n). (And maybe it can be done even faster with some kind of doubly linked list to store strings as list of elements, where a string is represented by a pointer into the list, a length, and a direction flag...something to think about).
Anyway, the permutation question is fraught with potential pitfalls. I'd be smart enough, I hope, to do all the above musings out loud to give the interview a chance to jump in and tell me "It's OK...I just want to see if you can write code, so go ahead with the recursive solution".
That second problem is straightforward. It's just binary search. The rotated array doesn't change anything fundamental about it--it just slightly complicates the check to see which half the target element must lie in. There will always be at least one "normal" half--that is, a half where all the elements are sorted. You can recognize a normal half be the left endpoint being less than the right endpoint. You check for the target in a normal half the usual way. If the target is not in the normal half you check, it must be in the other half (or not in the array at all).
As for what I get out of the interview - you're right, it's not going to tell me how good of a programmer the candidate is. But it will tell if they can code, and will give me some idea of their problem solving abilities. (I've also personally solved both questions without help in under 15 minutes each, though not under stressful interview conditions).
if i had to come up with a permutation algorithm as part of writing code, you'd better believe i'd look one up so that i'm sure i'm doing things optimally. i wouldn't trust myself to come up with the exactly right algorithm on the first try.
if i had to deal with some weird half-sorted array, i assume i'd be working in the same context as the problem and wouldn't have to make up a solution on the spot with limited details. why do you have a weird-ass data structure like that to begin with? that's the first question i'd ask.
personally i always ask a couple of simple questions (like FizzBuzz) and then talk experience. if you want to see a code sample, ask for one -- written on a computer, without someone hovering over the candidate's shoulder. coding solutions to weird questions on a whiteboard doesn't help anybody.
For the split array problem I rarely ask for code (only when I think it will actually help the candidate), it's just a discussion. It usually goes something like this:
Candidate: Well I can sort it first, then do a binary search.
Me: How would you sort it?
C: I'd use quicksort.
M: Can you do better than an nlogn algorithm?
C: Well I suppose since it's two pieces that are both already sorted, I can just find where they are split and then rearrange them.
M: How would you find the split?
C: I can go through each number until they stop increasing.
In addition to asking coding questions I always ask candidates about previous experience and projects they've worked on. Sometimes the answers to these questions are more important. Most of the people I have been interviewing, however, are recent graduates or students who are just finishing college and may not have much experience or many projects that really engaged them.
I spend a lot of time thinking about how I can improve interviews within the confines of how my company conducts them. I've stopped asking the permutations question as I feel that it has too much of the "aha!" factor in that either the programmer goes "aha!" and solves it or they don't.
I found about 10% nailed it right away with code that would compile and run. These were generally people who had been coding a lot recently.
Half of the rest (say 45% of total) got close: Minor syntax errors, logic errors, stuff that an IDE/non interview situation would have fixed.
45% just spaced. Couldn't right the for loops, conditionals. Couldn't write basic code.
Of those that passed: one had Masters in Library Science looking to change careers. The other was a fresh out of college CS major from Illinois State.
Next batch, I think we'll add another trivial question: count the number of vowels (a, e, i, o, u) in a string.
<?php
$string = "aeiouxabcd";
$checkfor = array('a','e','i','o','u');
$count = 0;
for($x = 0; $x < strlen($string); $x++) {
if(in_array($string[$x], $checkfor)) {
$count++;
}
}
echo $count . "\n";
I'm all for intellectual gamesmanship, but these are our professional equivalent of a doctor being asked to identify the difference between blood and water. You can do it. We know. Demonstrating that you can do it is not the point of the exercise. We do it to have a cheap-to-administer test to exclude people-who-cannot-actually-program-despite-previous-job-titles from the expensive portions of the hiring process.
<?php
echo strlen(preg_replace('/[^aeiou]/i', '', 'hello world'));If you're not weeding out these people with a 10-15 minute phone call you'll waste a lot of your and their time.
http://www.codinghorror.com/blog/2007/02/why-cant-programmer...
If it's for a programming position, the "paper" is lying in this case. If someone is claiming to have experience or qualification in certain areas that they can't even perform basic operations in, they're fraudsters.
It'd like trying to hire a surgeon and have someone turn up who doesn't even know what lymph nodes are. Dangerous and unhireable, but sadly a lot of employers put up with this sort of nonsense.
The last test I did help administer was for a VB+SQL job, and the first question was to write an example of a valid INNER JOIN. I'd say at maximum 25% of the candidates could do this.
Improving SNR? I did once have a potential employer get me to do a time-limited online test. If you wanted you could always stick your questions into one of them, so you can at least do the fizzbuzz-level screening without calling them in and sitting them down.
I bet that if you had asked for an example of a sql code which would list all the employees born before 1980 along with the department they worked for and the name of the head of that department, you would have gotten a much more useful result out of that.
That query is, incidentally, much more difficult to write.
Really, if you can't remember the difference between inner, outer, full and cross joins then you shouldn't be working with databases. Which was rather what the test showed us, frankly.
But we've cherry picked the CVs a little. And probably only interviewed 50 people over the past couple of years. (And hired 5)
Our success rate is surprisingly low.
You have multiple types of folds that could be made, variable on direction, orientation, and fold distance. The only one really pertinent to this problem is fold distance. A paper folded 50 times could be 51 * thickness, if you don't define that the paper must be folded in half each time. If you enforce that it must be folded in half it becomes: (2^folds) * thickness.
Why don't you ask your manager the following.
If 1/2x +1/2(1/2x + 1/2(1/2x +1/2(1/2x + ... = y, then x = ?
If can't get it in 5 minutes, he is not fit for his job.
It only checks if you can estimate the thickness of paper sheet and know powers of 2. Anybody can know that.
source: http://library.thinkquest.org/J002235/hard.html
u mad?
Well, it does make for exciting bitch sessions in IRC.
And now that you mention it, I have no idea either ^_^ ... except that it ought to be easy. In that last company where I was part of the hiring process I myself got the job only because I was the only one they interviewed who could pass their dry erase board tests (at the time they didn't have good pre-screening or access to a good candidate pool; I myself answered a want-ad). Tests that were to me so simple I barely remembered them (two decades of experience by then).