There is absolutely no purpose to knowing off the top of your head how long an ethernet address is, or even what system call will retrieve an inode (his bickering over stat() "filling in" rather than "returning" was bogus, for what it's worth). The top Google search result for each of these questions has the answer. Knowing these things isn't part of being a practicing programmer; knowing how to find out is.
Those functions return a error code, you pass in a stat structure and the function populates that structure.
He was saying (correctly), that they don't return (in the classic C sense) the inode. They return an error code.
To me that is a big difference...
int lstat(const char path, struct stat buf);
vs stat* lstat(const char *path);
2 completely different functions.
Btw, that is the only thing I really disagreed with OP on, the rest seemed just ridiculous.
It's a technical interview, the question should have been technically correct. "What function passes by-reference copies of inodes?"
"lsof just prints open files... you would use netstat, not lsof."
I tried correcting him, but he wouldn't listen and ended the call soon after.
I never received a call back.
~ $ lsof -a -n -c chrome -iTCP:443 | head -2 #sanitized output
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
chrome 1234 me 12u IPv4 12345 0t0 TCP 127.0.0.1:12345->127.0.0.2:https (ESTABLISHED)I personally wouldn't want to work with someone who wasn't able to understand what I mean (in such an obvious case, at least) and wasn't able to answer to that meaning.
(Of course, I'd also personally prefer someone who would point out that this is inaccurate, but do so in a charming and off-hand way, to make me feel comfortable. A high bar, maybe, but for a director that's definitely a bar they should clear).
Remember, you have to walk through the interview thru OP's mindset and how he took into consideration the interviewer's analness.
lstat has the same signature as stat: it passes the stat structure back through an output pointer.
Q: What does lstat return?
A: A struct
>> Wrong, it returns an error code
IIRC, you can return structs from functions in C. You have to access the values in the returned struct with dot notation, of course, like point.x .
Pre-ANSI C may not have had this, but later, it did. Remember reading it in the 2nd (ANSI) edition of the Kernighan & Ritchie C book, and also used it myself in some programs.
https://www.google.co.in/?q=can+you+return+a+structure+in+c
Edit:
Might want to consider the cost of copying, depending on the perf requirements, size of the struct, whether the function call is in a tight loop, etc.
These functions return information about a file.OS X: (OK, so I lied about the "fine" part)
The stat() function obtains information about the file pointed to by path
Get status information on a fileLinux:
int stat(const char *path, struct stat *buf);
stat() stats the file pointed to by path and fills in buf.
int stat(const char *restrict path, struct stat *restrict buf);
The stat() function obtains information about the file pointed to by path.
Read, write or execute permission of the named file is not
required, but all directories listed in the path name leading to the file must be searchable.
In a recruiting situation, if the recruiter is going all "right and wrong" on the interviewee, they should know these dirty details.
I also disagree on the ethernet address length. You know how long IPv4 addresses are, you know how long IPv6 addresses are, why would it be so extraordinary to also know how long MAC adresses are?
I think it could be useful to find out in an interview whether the applicant knows stuff because they have actually implemented low-level code and gained an intricate understanding, or whether they just did used some high level APIs and were never interested in more details than "I have a handle right here, it does all I need". For some positions that would be an important distinction.
Personally, if I were interviewing people, I'd hire the guy that explains something to me that I did not know, but that I find interesting and would have attempted to understand, too.
While I agree, I have seen interviewers where if he answered "fstat" they would have come back with "Wrong! fstat passes the structure back by reference, it does not return it!"
With this style of interview I can't blame him for thinking it might be a trick question and then trying to explain why he didn't say those other functions as an answer.
Why he's being interviewed for that position is a different question entirely, and I can imagine Google being totally right or totally wrong.
Take, for example, the sorting question. "Why is QuickSort the best sorting algorithm?" The answer being looked for was, "It has the best Big O."
And this is wrong. Its average case is O(n log(n)). Its worst case is O(n^2). Which do you call its big-O? Moving on, the average case of O(n log(n)) is matched by a wide variety of sorting algorithms. How do you choose one?
Here is a better answer.
QuickSort is a very simple to implement algorithm which achieves the lowest average number of operations on a randomly sorted list. Which is why it is so widely adopted despite sometimes being very slow.
However Timsort appears to be the fastest general purpose sorting algorithm for the mix of random and partially sorted lists seen in practice.
When I tend to notice that sorting is slow, generally that's a larger workload where some type of merge sort would be appropriate.
For instance, perhaps the interviewer asked "What makes quicksort a good sorting method," instead of "What makes quicksort the best sorting method"—a very small difference in phrasing. In that case, the answer of "It's not always the best, or even suitable" is still technically true, but much more wrong. (And an answer like the one you started with, "Its average case is O(n log (n)), its worst case is O(n^2)," would have been enough to pass... but sitting on the phone and arguing about storage topology is itself a failure.)
As I mentioned in another comment https://news.ycombinator.com/item?id=12702130 , my (five-year-old, faulty) memory of Google's SRE phone interview is that they asked another question here with a very small but important phrasing difference: "What is the signal sent by the kill command" instead of "What is the kill signal". If you make that change, the interviewee's answer of "SIGKILL" becomes wrong, and the interviewer is right to insist on SIGTERM (which would otherwise make no sense). It is a quite literal game of telephone.
(Again, I can also imagine Google being totally wrong and the interviewer mangling the questions.)
For question 5, you asked about an inode, and were told about an inumber, and got back an answer insisting that the inode was an index.
For question 6, maybe change "inode" to "information in the inode". The interviewee still has not figured out the distinction between an inode and an inumber.
For questions 7 and 8, apply the changes I suggested.
At what point do you decide that the interviewee is hopelessly arrogant and not worth your further time? And how do you get them off the phone gracefully?
Maybe around question 10, when they're quoting bits to show off and not saying the words that would actually let them communicate with other engineers like "SYN" and "ACK"?
No ill will is required on the interviewee's side, unless you consider refusing to waste time on bad candidates "ill will".
The conversation that I'd have to reconstruct has a very combative interviewee. Which would also fit said interviewee deciding to write up the article that I read. Which would mean that Google dodged a bullet.
I find it interesting to note that his site is down. There are a lot of possible causes, but it isn't good advertising for his webserver software.
But... the kill command is the command to send arbitrary signals. It sends them all.
I know this is irrelevant to the larger point of your post, and I'm sure that you know this already, but the worst case is the big-O. This is just another reason why "big-O" is not the most helpful thing to discuss in practice.
Big-O is a way of categorizing the growth of mathematical functions. Those functions can represent anything. It is wrong to talk about the big-O of an algorithm without specifying what you are measuring. Be it average operations, worst case operations, average memory, worst case memory, amortized average time, amortized average memory, and so on.
It happens to be that when we talk informally, we're usually talking about the worst case we are willing to think about. Quicksort's worst case is a sorted set, so we think of that as O(n^2). But then we turn around and cheerfully call a hash lookup O(1) because its O(n) worst case is incredibly rare in practice.
Thanks for correcting me!
I thought you were right at first but then realized what was going on. This is a pretty subtle point and mostly uninteresting for well-understood algorithms like quicksort. But one slightly less subtle point is that big-theta isn't average case, it is the combination of big-O and big-omega, i.e., bounded from above and below (possibly with different constant factors) by the same asymptotic behavior.
But, obvs, the answer is that you Bing it.
The rejoinder, of course, is that it's probably misguided to structure your recruiting around a spam filter.
Maybe I'm a bad programmer, but I don't feel like I would be a better one with that specific fact committed to memory. I dunno.
I do plenty of interviews, and so I do have some sympathy for the idea that some overwhelming majority of applicants simply cannot perform even the most basic coding tasks but are somehow trying to sneak in anyway, but at the same time I can't escape the suspicion that a lot of the stories are actually from badly-designed or badly-calibrated interviews gone off the rails.
I absolutely believe that the article we're discussing here gives a fair view of a Google phone screen, since I've been through it too and even got asked some of the same questions. The only reason I "passed" was that I recalibrated way, way down to meet the expectations and the technical understanding of the recruiter I was talking to (who did very clearly seem to be reading off a prepared script). This was surprising since Google had reached out to me to ask me to apply, which one would think indicates a confidence in basic technical skills, but if I hadn't caught that and adjusted how I was interpreting and answering the random trivia they threw at me, I likely wouldn't have passed the screen and would have been labeled just another impostor trying to sneak into a job I'm unqualified for.
So when I hear someone else talking about all the "unqualified" applicants they get, I can't help wondering how many really were qualified applicant talking to unqualified interviewer using unqualified interview process.
(disclosure: I don't work for Google, don't ever intend to work for Google, and in fact hung up on a later screening call out of frustration with the way they ran their process, which at least finally got their recruiters to stop spamming me)
My friends and I used to spend bar nights drinking over torturous interview questions (yes, I have always been this nerdy). For instance: we had a gruesome sequence of questions on how to implement the fastest possible traceroute that you could only clear if you knew about a trick using the IP timestamp option.
Later, I got (what I thought was) smarter about interviewing, and moved to more surgical questions. I'd ask candidates to debug a C program that segfaulted in malloc, or ask them to describe the utility functions they carried with them from project to project.
After taking over recruiting for a company that really needed to hire at a specific clip in order to balance sales and delivery, I'm embarrassed that I thought I was interviewing effectively with stuff like this.
You can't learn about someone's capabilities by putting them on the spot with trivia questions.
But that's not the point of these questions. These questions are a 5-10min phone pre-screen before getting to the actual interviews. They test if the candidate has experience in a given field, not if they can search for information or what are the precise bounds of their capabilities.
It's trivia, but it's trivia that is a reasonably high confidence proxy for experience in e.g. network programming/design (resp. other fields). If someone claims they have networking experience and don't know SYN/SYN-ACK/ACK it's in my opinion a large red flag.
The ostensible reason they get deployed (I say "ostensible" because we all know that in reality the on-site interview consists of the same stupid kinds of questions) is to keep the employer from wasting time conducting more sophisticated interviews for candidates who have no hope of passing. But that's dumb for at least two big reasons:
* The filters obviously reject candidates who would do well on more serious challenges --- worse, they do it insidiously, because you can't tell that they're rejecting good people, only that you're seeing fewer bozos, which makes them look like they work. In reality, a new norm has arisen where the most qualified candidates get to skip these processes entirely, because we all know they're a crap-shoot and don't want to lose good people.
* Properly administered work sample challenges actually take less employer time than these stupid trivia screens do. That means there's literally no purpose to the trivia screens whatsoever; they do nothing but harm.
In my last comment, I just wrote off the top of my head a sketch for a work sample test that addresses the same concern as the dumb TCP/IP trivia quiz from the original post. It took me I think something like 30 seconds to come up with it. Think about how you'd score that (remember: the bar here is "must be more predictive than that dumb trivia question"). I'm thinking something along the lines of "run the code and see if it opens a new TCP connection".
Assuming your team has enough sophistication to build work sample challenges like this, try to justify the trivia interviews. I think you can't.
SRE's are hired to fix outages and other problems asap, knowing trivia is very important then since at that point you might be losing a million dollars per second.
I think you're onto something greater. Maybe Google should hire more smart people who were developing in the 1990's as they're a nice, middle ground between ambitious, young folks and the been-there-done-that greybeards. Them realizing such people already know all the shit they're trying to teach their developers might be way to sneak older people into these tech firms. Haha.