[soham]

[Disclaimer: I run http://Interviewkickstart.com]

Thanks Aline. Excellent article, as always.

Not that any interview process is perfect, but another reason why the current process is not going away, is sheer convenience, especially for the fast growing core tech companies that don't have a pipeline problem. When you have hundreds of people applying for any open role, and you're under pressure to deliver products quarter after quarter, your incentive is to stick to a process that gives reasonable results, fast enough.

e.g. Google has estimated 40K engineers. With a 10 year average time on job (it's probably less), G is hiring 40K engineers every 10 years just to sustain itself. That's a massive operation and the incentive of any company at that scale, is to design a multi-layer, fast process. They are looking for 40K engineers that pass that process, not necessarily 40k best engineers from their pipeline.

Considering diversity with that little attention span is possible, but very hard to do. And like you said, technology is possibly the only way diversity hiring can be encouraged/enforced.

[pzh]

Actually, I remember reading that Google and Amazon engineers have an average time on the job of about 1 year. It seems most people just want to work there so they can put it on their resume, or maybe once they pass the interview process, they are confronted with the reality that not all jobs there are so glamorous--e.g. people probably imagine they'd be working side by side with Jeff Dean and his likes, but then they actually end up maintaining some internal system that keeps track of the stock in the Google cafeterias. I wonder if after ten years or so, a short stint at Google or one of the other big five would become a requirement to be taken seriously in the field...

[ashark]

I have an entirely unsupported hypothesis that much of Google's software/documentation inconsistent quality and seemingly strange product strategy can be explained by their preference for hiring "A" players or better, but only having enough truly interesting work for the smaller number of "A+" players they've got, so that at some point "A" folks get assigned something really boring but necessary and before long they're applying other places with Google on their work history so they can take on much more interesting work at some (possibly smaller) place that gives the boring stuff to "B" or "C" developers--or else they manage to get on or agitate to create some greenfield project, and that keeps them busy at least until the boring stuff on that project begins to overwhelm the interesting work. Result is there's too much churn among any personnel assigned to boring stuff for them to be very good at that kind of thing, as a company.

[flukus]

My theory is that google isn't filtering out the "less than A's" anywhere near as much as they think they are.

[zigzigzag]

Without a doubt that stat is because these companies have grown so fast. It's not that people leave after a year, it's that they have added tons of engineers in the last year (and have done so repeatedly for the last few years).

I worked at Google. Turnover was really low. 10 year average stay doesn't sound unreasonable for me if you select only the employees that have left.

[pzh]

Maybe I misunderstand the metric, but isn't turnout calculated as the average tenure of people who leave? If the companies just add more engineers, this shouldn't affect the metric (unless you also count the tenure of people who are actually still working there, but that doesn't sound like a good way to estimate churn rate...)

If that's the case, it seems there is quite a bit of confusion about this: https://www.bloomberg.com/view/articles/2013-07-29/why-are-g...

[zigzigzag]

You didn't quote turnover figures, you quoted average time on the job.

[leeny]

Yup. When you have a revolving door of people who want to work for you (often, despite your interview process), you're probably gonna be fine no matter what.

That said, folks at Google are putting a ton of effort and resources into diversity initiatives. But not at the expense of revamping the current process.

[Kephael]

I can't think of a single reputable company that I would be interested in working at in a SDE role where they do not conduct data structure and algorithm intensive interviews. If you want to work at a brand name company as a developer today, you must be able to solve these interview questions.

[jaimebuelta]

My main problem with this is the fact that, at certain point, your previous experience gets somehow irrelevant.

Have you been able to solve difficult technical problem in the last 5 years, which you can explain in detail? It doesn't matter unless you can code me from scratch a binary tree. Do you have domain experience about something the company work? Cool story, but tell me the proper API call to do this obscure operation.

I understand what's the point of that, I made technical interviews myself and I know is the game to play, but at some point it feel a little weird that you cannot leverage your previous experience and go talk the interesting, actually relevant parts, not the big O of quick sort algorithm...

After playing the game N times (and I don't think I'm particularly bad at it), it gets a little tiresome, I have to say...

[yarou]

I tend to agree with this sentiment. As my colleague aptly put, algorithms/data structure questions aren't really about whether a potential candidate can perform the job.

It's more about whether or not they are "one of us". I mean, if you couldn't be bothered to brush up on CS fundamentals, how can I trust you with the responsibilities that the job entails? That looks like a red flag to me.

FWIW, when I interview people, I ask actual problems I've run into, i.e. design and implement a sane concurrency system that's easy to reason about on an embedded platform with limited resources.