I'm sure it has been discussed before, but what factors push people away from say two-day internships? Is it because these things are so short that they too can eventually be gamed? Or is it because you need to have staff of the same specialty dedicating their resources to a potentially short-lived investment?
The Utter Uselessness of Job Interviews
261–270 of 410 posts
Re: The Utter Uselessness of Job Interviews
#262Earlier quoted context omitted.
According to `man ps` on my Mac, there are nearly seventy of them - how many did he want you to know?!
It's been a long time since I interviewed an ops person. But when I did something like this, I'd ask, "Name as many arguments to ps as you can." (Or ls, also good.) I didn't really care about which flags they knew. What I was looking for was a pattern. Anybody good knows some arguments cold. Often they know them so well as part of a phrase that they have to think about what the individual ones mean, which tells me th…
dangerous because they prefix things with sudo?
Re: The Utter Uselessness of Job Interviews
#263Earlier quoted context omitted.
Making sure I understand you: When you refer to work sample tests here, that refers to the crypto challenges and things like that that you published at Matasano? And you're saying that was much more predictive than the list of facts methods, right?
That's what people ordinarily assume I mean, but while our work sample challenges were similar to the cryptopals and Microcorruption stuff, they were not the same, or even derived from them. They were designed specifically to qualify candidates, and in fact predated our public challenges.
Ahh, interesting. Would you mind sharing an example of how they were different, or how the fact that they were specifically for qualification changed the thought process? I'm working on making tech interviewing better and am fascinated by this stuff.
Re: The Utter Uselessness of Job Interviews
#264Earlier quoted context omitted.
That's a big red flag, at least in a Google setting. The reason is because when your dataset is in the petabytes, any algorithm bigger than O(N log N) is not going to terminate. You're not going to get any answer at all; your MapReduce is going to sit there burning CPU time for a day, and then you'll kill it, and you won't have any idea what went wrong. (This is learned from experience, if you couldn't tell.) In a st…
In my experience as a Google engineer, this is mostly false. None of the work I or any of the people I know well at Google is on petabyte datasets; most people just aren't on the hot path of indexing/websearch/youtube. In fact almost none of the stuff I was asked about in my interview has been relevant to my work. I have thought about complex algorithms two or three times in the past year.
What department? I was in Search and used that knowledge all the time, and also did rotations on GWS, Google+, and GFiber. Certainly I used less of that knowledge for GWS (where everything you need is in-process) and for GFiber (where I was working on marketing & customer signup - the job req for this was actually different, and both interviews & job duties were much more like a traditional SWE job in other companies). But even Google+ needed a lot of algorithmic complexity knowledge; G+'s scaling needs are similar to Twitter's, and we know how that went.
Perhaps it has changed as well; when I left (2014) they had just started encouraging engineers to focus on one particular task, with the architecture already defined, while when I started (2009) there were still a number of problems of the form "here's a feature we want to add; here's the data we have available; how can we build it?"
Re: The Utter Uselessness of Job Interviews
#265Earlier quoted context omitted.
Of course. For example, many of the questions for technical interviews involve knowing which data structure to use in a given setting, and applying it to find a solution. The interviewee is more than welcome to study data structures and interview questions about data structures. A poor student will just memorize questions and answers by rote without really understanding the data structure in question. The good studen…
And yet most people are memorizing solutions to hundreds of different questions and getting great jobs because of it. I know this because I have several friends who do this.
Well, at least hope that some of that information sticks.
Re: The Utter Uselessness of Job Interviews
#266Earlier quoted context omitted.
Yes. This is the reality of distributed computing: most of the problems you want to solve do not have off-the-shelf libraries. Rather, you need to know an algorithm, and various algorithmic-design techniques, well enough that you can decompose it into steps and then recompose steps so that they can be partitioned among many different computers, with appropriate failure modes if machines or network connections go down…
Is that actually a majority of jobs at Google? I know something about the work that several of my friends working as SREs and SWEs do and it doesn't sound like it involves a lot of distributed systems programming. Let's say you work on some part of Android. Obviously you need to interact with things like Google's build system which are distributed, but are you really implementing some distributed computation in the c…
It was at the time I was there (2009-2014). There's another Googler above who says it's not like that anymore, which is possible, but these were things you needed to know across Search, GMail, YouTube, Plus, Docs, and Infrastructure while I was there.
Re: The Utter Uselessness of Job Interviews
#267Earlier quoted context omitted.
This is a stupid trivia question. I use ps -ef and leave it at that. In my entire career I've rarely needed anything else and if I did I would look it up but never enough to remember. To base an interview question off of that speaks volumes about you.
I agree, and it's interesting that you know -e, while I've memorized -axuf ; I guess it's more portable? Again, this is one of those, "Here's what I've got cached, and here's where I'd look up what I don't know offhand" questions.
No, "-axuf" is a weird mixture of BSD and POSIX syntax.
From the ps manpage:
Note that "ps -aux" is distinct from "ps aux". The POSIX and UNIX standards require that "ps -aux" print all processes owned by a user named "x", as well as printing all processes that would be selected by the -a option. If the user named "x" does not exist, this ps may interpret the command as "ps aux" instead and print a warning. This behavior is intended to aid in transitioning old scripts and habits. It is fragile, subject to change, and thus should not be relied upon.
Re: The Utter Uselessness of Job Interviews
#268Earlier quoted context omitted.
It's been a long time since I interviewed an ops person. But when I did something like this, I'd ask, "Name as many arguments to ps as you can." (Or ls, also good.) I didn't really care about which flags they knew. What I was looking for was a pattern. Anybody good knows some arguments cold. Often they know them so well as part of a phrase that they have to think about what the individual ones mean, which tells me th…
They'll usually look a bit uncomfortable, because they are the sort of person who likes knowing things. So the process is, in fact, designed to make people feel uncomfortable, for a little bit (or at least you're definitely aware that this is a frequently occurring side effect). Does that not suggest to you that there may be a negative tradeoff at play here? (To wit: yes you do manage do efficiently extract a few bit…
I think part of the point may be to select for people who don't consider "being interrogated" to be a contest. There are plenty of folks who are just like "Here's what I know, here's what I don't know, you decide whether you would want me on your team. If you don't, that's fine, I'll find another team to join." Then there are other folks who, when they're asked a question and don't know the answer, feel like their self-worth is under attack. The latter group can be really hard to work with, and can do a lot of damage to a team.
I had a PM friend who would try to push the bounds of a candidate's knowledge until they gave up and said "I don't know". The actual knowledge wasn't the point of the question: it was that they could say "I don't know", because PMs who can't tend to make life miserable for the engineers & other teammates who work with them.
Re: The Utter Uselessness of Job Interviews
#269Earlier quoted context omitted.
Making sure I understand you: When you refer to work sample tests here, that refers to the crypto challenges and things like that that you published at Matasano? And you're saying that was much more predictive than the list of facts methods, right?
That's what people ordinarily assume I mean, but while our work sample challenges were similar to the cryptopals and Microcorruption stuff, they were not the same, or even derived from them. They were designed specifically to qualify candidates, and in fact predated our public challenges.
Just to further clarify, by work sample you do NOT mean an example of previously produced work? This still seems fickle: my dozen years of work output (for example, building and running a site with perfect uptime for millions of users) is not as valid an indicator of my future performance as how I happen to score on some arbitrary timed test?
Re: The Utter Uselessness of Job Interviews
#270Earlier quoted context omitted.
It's easy to present data that shows flaws with today's interviewing. It's a lot harder to present a better way of predicting candidate performance in the workplace, along with substantial data that indicates it's better than today's methods. Corporations would love more effective ways to determine effectiveness/performance before hiring. Interviewing is terrible, but that doesn't mean there is a better option.
We have had a better way for decades, its banned. What do you think all these algorithm questions are supposed to do?
Any evidence to say that algorithm questions are a better indicator of job performance? Most development work isn't algorithm heavy at all.