Comment by falcolas
11 years ago
If only whiteboarding interview processes actually weeded out false positives.
In practice, they select for people with good memorization skills. If you can remember the details on a ten dozen different algorithms and data structures, you can pass one of these without having a single lick of creativity or skill.
I say this as an employee who has worked alongside many unskilled drones who made it past the algorithmic interview process.
I agree.
I recently interviewed for a security engineering position at a startup, and while I got offered the job, the interview was quite silly.
The first thing I was asked to do was to write a lisp interpreter. It was a pretty trivial task, but it left me scratching my head since not only did it not tell them about whether I would be qualified at all, but I had explicitly avoided writing parsing code since I found ANTLR during undergrad.
In the end I wrote a basic stream abstraction and wrote my lisp interpreter on top of it with no real difficulty, but it was a completely stupid question. I told them on the third interview that they weren't asking me anything relevant and I still got another question later on about how to iterate over a tree in a specific order.
Part of the issue was that most of my interviewers were fresh out of college, it was literally their first job and they had no idea what to ask besides the kinds of questions they had been asked in their own interviews.
That last sentence is telling. Would you even consider working there if they had no idea what to do? I have worked at established companies where there is clearly nobody at the helm and it is frustrating.
I considered it for a bit, they were hiring their first security engineer, so it's understandable that they weren't very sure what they were hiring for.
In the end there were a lot of other issues that made me not take it, but not knowing what is necessary seems pretty typical wrt security. However, in those situations you want to have wide latitude to affect change because the thing they hire you to look at is probably not really where their problems are.
That's a great point.
Infatuation with "coding competitions" and high flux intelligence tasks is often an anti signal.
Sure, what they demonstrate looks good at face value, but unless you attach a micromanager over their tasks, they'll constantly deviate to the new-shiny every week instead of staying on task for the long haul.
I know even YC has been bitten a few times by accepting people who are top-performers in very narrow contexts (e.g. people obsessed with winning coding competitions every single weekend) only to see they can't do anything coherent for more than a week at a time.
Just because someone is great in a narrow context doesn't mean they can carry that over the months and years needed to deeply iterate (and suffer through the low points) on successful projects.
I'd generalize your point a little more - for a given level of life success, intelligence will anti-correlate with other hire-ability skills like work ethic, diligence, attendance, emotional stability, professionalism, etc.
Basically, imagine that there's two ways to graduate college with a CS degree - you're either the kind of person who's smart enough to get things if you work your ass off for them, or you're a genius and you coast through. If you're a genius and you work your ass off, you get a doctorate or found a startup, and aren't in the candidate pool. So you wind up with a choice about what to compromise on: work ethic, or smarts.
Ideally, you compromise on whatever makes the least difference to your organization, compared to your competitors. Hiring smart/motivated people out of non-traditional backgrounds is a great option for this.
You hardly need to be a genius to get through a CS degree without 'working your ass off'
1 reply →
Which is why I hate HackerRank being used as a screening tool.
That's not what the interview process is like at all.
They're more interested in how you approach real world issues (the questions I got asked were conceivably real-life issues a company like Google would face with its products). If you can solve that issue by applying efficient and well understood data structures and algorithms, then that indicates you understand the problem space and solutions that may apply.
It's not like they get you in a room and ask you to draw a linked list or a binary tree.
I'll be starting at Google in a week and a half. I can't go into specifics, but I can say this:
I had two phone interviews - the first had quite a few questions about my prior experience (over a decade) and how to approach real-world problems from a high-level, including some that I had worked on at my current position. The second was primarily purely technical, but did have some more theoretical/project-management-y type of questions. In neither one was I required to write any code.
On-site: one interview was entirely whiteboard-coding (in a collaborative style), on a set of related generic problems. Next was one with a set of problems related to my experience. Third was almost entirely telling war stories. Last two were some generic graph-theory-type problems and some simple problems involving data structures relevant to the my area of experience.
As I hadn't interviewed for anything in 11 years, I did spend some time brushing up on my basic algorithmic theory, and essentially followed Steve Yegge's suggestions. I honestly think I probably could have done the vast majority of it without any studying, but spending time practicing solving problems on paper (with a countdown-timer as an artificial pressure-inducing device) certainly did help me, I think, in the on-site. No amount of memorization could have helped with most of it, aside from basic knowledge that anyone who's taken Data Structures should know.
I didn't find the process to be insulting at all; it was an enjoyable challenge. Everyone I talked with on the engineering side of things I can only say the best about, and so far as I can tell the team I'll be with has some really great people. I am a more senior developer, so perhaps I got a different experience than some.
This sounds like a huge improvement from when I talked with them a few years ago.
1 reply →
My experience wasn't a real life type one more academic instead. My interviewer was really late and refused to let me finish my data structure implementation to optimize a single method instead. When we finished it was time for him to go. He wouldn't let me go back to finish my data structure as he didn't have the time.
I was later declined. Had a couple of friends at google ask the interviewer. He said I was declined for not finishing my data structure.
Their interviewing process was quite frustrating. I'm fine with getting declined but not under those circumstances.
Your story can't be true because interviewers do not make hiring decisions at Google.
2 replies →
The important part of the "realistic" process is the part where you go from "the crawler's indexing is too slow" to "it might be because it allocates a lot of little bits of memory; it needs to first generate a BST of outbound link weights, and then functionally invert that into a second graph with a bunch of inbound link weights, and then inject all that into the PageRank matrix. You could probably save some time (though at the cost of memory-safety) by inverting the first BST in-place."
Once you get to that point, though, if they asked me "and how would you invert the tree in-place?" I'd answer "well, first I'd make sure we aren't just using a tree structure that already knows how to invert itself, or could easily be extended to know how. Then, assuming that didn't pan out, I'd google 'in-place invert binary tree' and read three or four solutions that already exist to burn the semantic structure of what I'm about to write into my head so that I don't subtly screw it up and have to fiddle with it for the next hour when I could be coding something else. Then I code it."
And that should be enough.
One of my interviewers at Google asked me to implement a balanced tree insert on the whiteboard in C. After doing so he immediately told me it wouldn't work. I searched futilely for a minute or two to find the problem before he condescendingly pointed out I had left out a semicolon on one of my statements...
Another in the same interview got in my face (this should be easy) when he thought it was taking me too long too multiply two numbers like 637 and 41 during an estimating problem. I understand the point of most of these questions is quick and dirty estimation (600 x 40), but seriously...
RE your second paragraph, it's easier than it sounds.
637 is an awkward number, we'll start by rounding up to 640: 640 * 2 = 1280, anyone in tech knows 2x that is 2560.
Make up the missing 3: 3 * 4 = 12, 2560 - 12 = 2548.
2548 * 10 = 25,480.
25,480 + 7 = 25,487
25,487 + 30 = 25,517
25,517 + 600 = 26,117.
That said, I did make a screw up when calculating it, and added the 637 before multiplying by 10 (which may have been the differentiating part of that question, combined with the intentional stress, to see how you cope with pressure? Although I didn't sleep last night, which might be the cause :D). I dunno if they wanted you to do it as quickly as 600/640 x 40 though, which obviously makes it much more difficult.
Afterthought, due to sleep deprived state, quicker way to solve:
600 x 40 = 24,000 40^2 = 1600 25,600 quick and dirty, for accuracy: 3 * 40 = 120 25,600 - 120 = 25,480 25,480 + 600 = 26,080 26,080 + 37 = 26,117.
Sorry, this comment turned into a bit of a ramble.
2 replies →
Perhaps it is an ego trip for the interviewers?
> It's not like they get you in a room and ask you to draw a linked list or a binary tree.
And yet the OP was turned down for not being able to invert a binary tree (based on limited information, etc etc.)? What do you feel that is, if not a "whiteboard this algorithm" question?
As for many of the other companies who try and emulate Google - this is exactly what they do.
> And yet the OP was turned down for not being able to invert a binary tree
Your source is a series of salty tweets.
2 replies →
There are tens of thousands of employees at Google. Most of them interview. People are different.
1 reply →
That said, I recently heard about a Google interview where the interviewer asked the question and left the room for 30 minutes while the candidate white boarded.
Obviously he didn't give 1 shit about "how you approach the real world issues".
They literally had me do a deterministic finite automaton problem.
Ok, on the one hand, you should be able to answer the question with, "Get a standard-issue POSIX-conformant regex library. Next question!"
On the other hand, knowing that DFAs are equivalent to regexes are equivalent to NFAs is already a step of theoretical knowledge that any "Just let me write code" so-called "dev" is likely to complain about being asked for.
5 replies →
I think what Google tries to find are the engineers with creativity, skill and ability to work intelligently at a problem which they haven't seen before.
It's important to know how a person approaches a hard new problem and how easily or not they give up. I'd guess that a person who didn't solve a hard problem, but got close enough by displaying creativity, curiousness and a solid thought process might have an edge over a person that implemented a familiar algorithm with ease but got a little flustered, and didn't show much creativity or inquisitiveness, when challenged with something new.
I think you want to think that way, that whiteboard interviews have a shred of competency about them. I bet you dollars to doughnuts though 9/10 times a company will hire someone who can regurgitate algorithms rather than an eccentric who can't get them right but thinks really cleverly.
It seems this criticism is of the interviewer making a poor decision based on missed/incorrect observations, not with the whiteboard interview itself.
Whiteboard interviews might miss eccentrics who can't express their clever thoughts verbally or visually, but it can depend on how tuned in the interviewer is to these eccentricities or how much value their team puts on expressive skills.
Algorithm/data structure interviews, whiteboard or not, also have the added benefit of being exceptionally good at eliminating candidates that:
1) Drastically misrepresent their skills
2) Give up easily at difficult tasks
3) Don't seek help from others
4) Frequently have a bad attitude
1 reply →
On two occasions I have "re-interviewed" current or past developers who wanted to move up from working on extremely simple low-complexity code / sysadmin work, and start working on our flagship project. In both cases the team leads and I didn't think these people were qualified to do so, but the candidates were really convinced they were. These were employees who had come into the company through non-standard channels, so hadn't experienced our normal interviews.
I had them attempt to solve the problems on a whiteboard that I would give to our intern candidates. Both totally bombed hard, and our other "re-interviewers" had the same result when they asked some design-related and algorithmic related questions.
This wasn't "regurgitating algorithms". It was basic problem-solving and software design. From their track record of development we didn't believe them to be qualified (despite their own opinion of themselves), and they only confirmed it by totally bombing the "re-interview" process (which was identical to our normal interview process).
1 reply →