Not sure about Google but in IBM when I was conducting tech interviews I was looking more for team members to help me complete the project rather than trying to project an authority figure.
The relationship was never adversarial and if you know how desperate we were to get good skills there is not much option to take the high ground.
The poster is correct that open ended questions that reveals the work ethic of team members are much more important than solving algorithms and hard problems. Intelligence is over rated.
My (pre?) interview with Google was little more than trivia questions. Example: the numerical value of SIGTERM. I could have talked about signals and how they were used for 20 minutes, but a nontechnical phone interviewer just wanted trivia answers.
The non-technical recruiter needs these trivia questions because they need questions with single answers that allows them to separate people with no technical knowledge and people with technical knowledge. The easy way to get past this barrier is to get a referral, then you start at the technical interview.
When I was at Google, I worked in a tiny office, and I was friends with the recruiter who worked that office. A couple of times she asked me to vet the answers to the non-technical questions, because if the candidate went off-script in any way, she simply couldn't tell if it's a wrong answer or a more in-depth answer than the script anticipated. This wasn't part of my job, and if our office wasn't so tiny we wouldn't have had any contact, and she wouldn't have had any engineers to ask.
I want to think that’s a terrible question - checking whether they have the signal table memorized is a hilariously bad way of trying to assess someone’s fitness as an engineer.
On the other hand, there’s some signal (sorry) on the nature of the work you’re doing in whether SIGTERM (15) is imprinted in your brain from near-daily appearance on your screen, or not.
I don't think so, unless you are referring to some kind of atypical terminal work. I just tried killing a console program and I see "Terminated: 15". That's not a line I even recognise - it's not common or important enough to bring to my attention.
I would say a vital command-line skill is having a good filter to ignore what's irrelevant.
This is really absurd question to ask. Besides kill -s SIGTERM or even htop does the job. But like other commenters have pointed out the questions really depends on the person as there is no specific decided questions.
I sympathize with the general idea however this specific question isn't very representative of it.
Signals 9 and 15 and much more well known by their respective value than their symbolic name. They are everywhere in program output and log files and if those things are your daily work then you recognize this whether you want to or not.
It's like if you have touched computer code in any language then you probably know that 65 is A. Not because you have useless trivial memorized but just because it figures every time you look at string values for some reason. In one sense it is useless trivia, but on the other hand a programmer who never stumbled on ascii codes must have lived in an unusually insular bubble.
> Signals 9 and 15 and much more well known by their respective value than their symbolic name. They are everywhere in program output and log files
I have never written a program that outputs a signal number to stderr or a log file. And grepping the logs on a server with nearly 800 days of uptime, I can find only five references to signal 15, from months ago.
> It's like if you have touched computer code in any language then you probably know that 65 is A. [..] a programmer who never stumbled on ascii codes must have lived in an unusually insular bubble.
20 years of programming and doing things like making custom fonts. I couldn't remember the ascii code of 'A'.
Recruiters ask horrible questions. If the recruiter has to ask you a technical question, it will be a bad question, because the recruiter doesn't have the expertise to understand the answer.
So you're left with bad questions which have single answers, mostly involving rote memorization.
But the recruiters are told by the SRE team to ask questions like this to candidates before they get a phone interview. I don't see any value in that, but then I don't work as a Google SRE so I don't know what is important to them. It is also possible that they are lacking SRE interviewers so they need to ask stupid questions to get down the amount to reasonable levels.
Another thing that isn't transparent to outsiders is how frequently candidates are shopped around if it becomes obvious they aren't a great fit for the role they were recruited against. I can't tell you how many times I've been asked if I'm interested in candidates that started out as SRE, CE, PM, or other roles. As mentioned, recruiters are paid on hire rate, and it's in their interest to ensure that strong Google candidates are identified and presented to as many potential hiring managers as practical.
Additionally, it's common for interviewers to interview for multiple different groups (as an additional tech interviewer, a xfn interviewer, a Googleyness interviewer, etc), so exposure to job requirements can be reasonably broad at the interviewer level.
As I imagine many suspect, calibrating interviewers is hard, and always has been, for a company hiring roughly 10,000 people every year.
It was indeed an SRE question. Followed by a series of algorithmic complexity questions which I happened to get correct based on barely-informed guessing, having never taken an algorithms class.
The poster is correct that open ended questions that reveals the work ethic of team members are much more important than solving algorithms and hard problems. Intelligence is over rated.