So, anymore I don't have much of a problem with simple coding questions to filter out total non-programmers (fizzbuzz, your calendar problem, etc.).
But the whole stand on one foot and implement a red-black tree in bash script on the whiteboard while I peck at my smartphone and sigh every time you pause to think has got to freaking stop.
This is a much bigger deal to me than difficult algorithm questions. Shitty interviewers give shitty interviews, regardless of what kinds of questions they ask.
The worst interview I ever had was like this. The guy showed up late, told me he forgot he even had an interview, gave me a strange question with little detail, and told me to start coding. Then ignored me for an hour while he typed on his laptop. Even when I directly asked for feedback to make sure I was solving the problem he asked and not a misunderstanding, he gave me basically no feedback. I've had interviews that I bombed before, but this was the first and only time that I felt like I bombed an interview and it was utterly not my fault. It was also the only time I've had a bad interview that actually ruined the rest of the day for me because it threw me off so much.
The only good answer to that is "I can't imagine why I'd ever need to do that, and if I had to anyway, I'd use a 3-2 tree instead because it's almost as good and nobody ever gets red-black trees right the first time."
...someday I'll find an excuse to return a 418.
They spend very little time staring at http error codes. Like, none.
"I am not making this up. It's a real problem. "
No, it's a survival bias. You have no way of knowing how they perform, unless you hire them, but you don't hire them, because they can't pass your interview process.
There are many reason why someone capable and experienced would "fail" an interview like that. But ultimately it just doesn't test for skills related to software development.
Be serious.
Experience taught me not to be insulted about those questions. They guarantee all collegues will be able to pass them.
http://www.geeksforgeeks.org/given-n-appointments-find-confl...
It requires the simple comparison you mentioned, but is far more complex to come up with an efficient algorithm. Needless to say, I totally failed that one. Never heard of an interval tree until I looked it up after the interview. It took me just a moment to look it up with my awesome google skills and if I had to actually use that, I could copy paste that code in an instant :-) Even better, I could find a library and not even have to copy paste.
One time I was working on a language translator at my actual job. I was storing formulas for excel columns in a database and they had to be translated from their representation in the database to the excel formula language. It turns out that the columns had dependencies on one another and they had to be processed in dependency order. This required something called a topological sort. Again, something I had never heard of before I encountered this problem at work (I do have a CS degree). But I found the solution by a quick google search and employed a library that was already in use in my client's software that contained that algorithm.
That's the actual skill that's valuable: translating your requirements into a bunch of search terms that will quickly give you the name of the algorithm you need. (and obviously building the inputs / working with the outputs of that algorithm). Yeah, I guess if you already have all of those in your in your brain already you might save some time, but what about when you encounter a problem you don't know how to solve?
A natural assumption is that two appointments conflict if their times overlap.
The example instance of the problem gives this as input:
> Input: appointments[] = { {1, 5} {3, 7}, {2, 6}, {10, 15}, {5, 6}, {4, 100}}
The problem spoke of "appointments in array" and this is an array, so apparently {1, 5} {3, 7}, {2, 6}, {10, 15}, {5, 6}, {4, 100} are the appointments themselves. So we have 6 appointments.
So I'd guess that {1, 5} means an appointment that starts at time 1 and ends at time 5. That {4, 100} concerns me, though...if the numbers are times there is no obvious unit of time for which all of these appointments make sense.
They give this as the expected output for the above input:
Output: Following are conflicting intervals
[3,7] Conflicts with [1,5]
[2,6] Conflicts with [1,5]
[5,6] Conflicts with [3,7]
[4,100] Conflicts with [1,5]
So that means my interpretation of the notation {x, y} on input meaning an appointment from time x through time y is not right.
Another idea is that {x, y} means person x and person y have an appointment together, and two appointments conflict if the same person is involved in both. Nope...that doesn't give the sample output either.
OK...maybe the sample output is wrong. So now I grabbed their code and compiled it on my Mac and ran it. It produced this output:
Following are conflicting intervals
[3,7] Conflicts with [-1960454340,32767]
[2,6] Conflicts with [-1960454340,32767]
[10,15] Conflicts with [-1960454340,32767]
[5,6] Conflicts with [-1960454340,32767]
[4,100] Conflicts with [-1960454340,32767]
Anyway, I see that there is a function in there to determine if a pair of appointments overlap:
// A utility function to check if given two intervals overlap
bool doOVerlap(Interval i1, Interval i2)
{
if (i1.low < i2.high && i2.low < i1.high)
return true;
return false;
}
Putting a printout in doOVerlap to see how it is getting used:
// A utility function to check if given two intervals overlap
bool doOVerlap(Interval i1, Interval i2)
{
cout << "check " << i1.low << "," << i1.high
<< " against " << i2.low << "," << i2.high << "\n";
if (i1.low < i2.high && i2.low < i1.high)
return true;
return false;
}
Following are conflicting intervals
check 1,5 against 3,7
[3,7] Conflicts with [1,5]
check 1,5 against 2,6
[2,6] Conflicts with [1,5]
check 1,5 against 10,15
check 3,7 against 10,15
check 1,5 against 5,6
check 3,7 against 5,6
[5,6] Conflicts with [3,7]
check 1,5 against 4,100
[4,100] Conflicts with [1,5]
I'll leave it to someone more curious than I to figure out what is wrong with their "solution".
my @appt = ([1, 5], [3, 7], [2, 6], [10, 15], [5, 6], [4, 100]);
my %active;
my @endpoints;
for (my $i = 0; $i < @appt; ++$i)
{
my($start, $end) = @{$appt[$i]};
push @endpoints, [$start, 1, $i];
push @endpoints, [$end, 0, $i];
}
@endpoints = sort {$a->[0]*2+$a->[1] <=> $b->[0]*2+$b->[1]} @endpoints;
foreach (@endpoints)
{
my($time, $side, $which) = @$_;
if ($side == 0) {
delete $active{$which};
} else {
print "$which overlaps $_\n" foreach sort {$a <=> $b} keys %active;
$active{$which} = 1;
}
}
When you see an end time, you can delete the appointment from the hash. When you see a start time, the appointment that supplied it overlaps with all the appointments currently in the hash.
That's what I was looking for as a hiring manager.
A genuine interviewer (and I realize several/many may not be genuine) is solely trying to figure out if the candidate has these types of reasoning skills.
Let me phrase it this way: By asking a common CS question, you'll get people who simply memorize answers/algorithms. By asking something obscure that is rarely known, you can try to get a glimpse into someone's thought process, which is infinitely more valuable than rote memorization.
The grandparent seems like the problem solving equivalent of yelling "think fast" whilst tossing a basketball at someone's face to test reflexes.
If you're hiring a point guard, isn't testing their reflexes by tossing them a basketball a reasonable approach?
This is the closest I can get to actual project work in 45 minutes.
My standard coding question is a funny-looking prime sieve. If someone isn't familiar with one, we can work it through together and I'll have a much better idea of their learning potential & what they'll be like to work with than the intern straight out of their Algorithms final.
That's what the work sample test does. It doesn't have to be given off site.
I think the point here is more about how experienced programmers track records are not enough to prove they can do the work sometimes.
Using whiteboard questions to prove ones competency can backfire as well in cases candidates are not really prepared but learned to game the system.
The point of my coding interview isn't to give a positive result if the candidate can program a computer. It's a test that's looking for non-programmers.
There might be "false positives", but if I avoid well-known memorizable questions, there won't be "false negatives".
Tell me you're kidding... that this is just a contrived example. please.
The time zones in calendar appointments can change, if there's a switch between standard time and summer time.
You need to know when is the hour set back by 1 hour, and in that case sometimes the answer is ,,maybe''.
I was working at a small phone company, and handling the switch between time zones were not just non-trivial, but they caused hard-to find bugs, as these things happen only twice a year.
Once they've got the comparison out of the way, you can bring up those issues and see where they grow their implementation.
There are people out there (not you, obviously) who can talk their way into an interview for programming jobs that they simply can't perform. We're talking about no skills whatsoever, apart from the ability to sling buzzwords around enough to impress a recruiter. God only knows how they get their degrees, but they have them.
Simple, straightforward programming questions that aren't already on the Web are like an immune system response to these non-programmers who interview for programming jobs. I'm truly sorry when a real programmer feels insulted when I ask them something like "given the starting and ending times of two calendar appointments, write an expression that's true if they conflict", because it's not their fault that there are people out there who will struggle for 20 minutes thinking about how to solve it before trying something like a doubly-nested loop over all the milliseconds in both intervals, testing for equality.
I am not making this up. It's a real problem. if you can program a digital computer, you have nothing to fear from a good coding interview. And if you have a better way to reliably identify the non-programmers, I'd love to hear it.