I've heard that list of questions before. They sound very old.
Some of the answers are out of date. It's been decades since "stat" actually returned the contents of the inode structure on disk. There are lots of different file systems now, with different internal data structures. "stat" gives you a standardized result regardless of what's physically stored. Does ZFS even have "inodes"?
TCP packets don't have "types". They have 9 bit flags.
SYN, FIN, ACK, and RST are the important ones. There are others, PSH and URG (obsolete) and NS, CWR, and ECE (congestion notification that never really caught on). That field is not an enum.
Quicksort does not have the best "big O". There are pathological cases for Quicksort. There are binning algorithms that can beat O(n log n), going back to SyncSort from the 1960s.
Bit counting by table lookup went out years ago. If you make the table big enough to be useful, you cause cache misses. There's a population count instruction in CPUs with SSE4, which by now is almost all x86 machines in active use.
MAC addresses are traditionally 48 bits, but the IEEE is pushing EUI-64, which expands them to 64 bits. Traditionally they were 24 bits of vendor ID, 24 bits of serial number. Address space problems. They also were once fixed in the hardware, but now big shops change them dynamically to make cloud routing ("software defined networking") work.
Disagree; there is such a thing as behavioral / fit, and I'd rather have someone neutral in there (not just the hiring manager), and that person should be staffed out of HR.
Google needs to overhaul its hiring practices if people who are not technically oriented are involved in the hiring process.
As a fellow software developer, this is pretty embarrassing that the interviewer wouldn't even pass an entry level course in college in any relevant degree program.
This must be some kind of joke. That's first-year student level of naivety here! (And I'm unfair to most students.)
I remember learning about sorting functions, when I was a teen (in the 80s), and even in the book it was NOT written that it was the BEST method, and it was an entry-level book, for beginners.
> Recruiter: I have to check that you know the right answers.
Sums up the whole thing I think. It's impressive.
Why do they even need a HUMAN then? Just use an online test, it won't be worse.
> You should learn the Linux function calls, how the TCP/IP stack works, and what big-O means to eventually qualify if you are interviewed at a later time.
The level of arrogance and stupidity is stunning (especially after the previous questions/answers).
If this is exactly what happened, and not an exaggeration, it's incredibly embarrassing. If it had been me, I would not have hesitated to have a few strong words and would have put the interviewer to his/her place. Sheesh. That attitude of theirs is almost beyond belief.
I'm almost reluctant to believe that it really happened, especially in a big technical company (even if the recruiter is a third party). Unfortunately, after many years in the field and meeting a HUGE number of arrogant & clueless people with bad attitudes, I suspect it is probably true.
I've always been surprised that even intelligent recruiters don't seem to realize that one of the things that a good candidate will find most off-putting is a recruiter trying to have a technical conversation or asking technical questions.
To be fair though, I thought his answer about inodes was wrong. Seems to me the candidate was defining an inode number, not the inode itself.
Why does a recruiter conduct a technical interview ?????
This a recipe for failure. Let a recruiter check for other non technical stuff.
And let an engineer do the technical questions and the evaluation.
Also, worst is to have prefab questions and answers.
The problem is that a non qualified person is interviewing a candidate for Director of Engineering. These questions may be ok for a college hire for an entry level position. And even then it cannot be treated like a simple yes no thing.
The interviewer is also very bad at his job. You can replace him with a simple Google form.
Some of the answers are out of date. It's been decades since "stat" actually returned the contents of the inode structure on disk. There are lots of different file systems now, with different internal data structures. "stat" gives you a standardized result regardless of what's physically stored. Does ZFS even have "inodes"?
TCP packets don't have "types". They have 9 bit flags. SYN, FIN, ACK, and RST are the important ones. There are others, PSH and URG (obsolete) and NS, CWR, and ECE (congestion notification that never really caught on). That field is not an enum.
Quicksort does not have the best "big O". There are pathological cases for Quicksort. There are binning algorithms that can beat O(n log n), going back to SyncSort from the 1960s.
Bit counting by table lookup went out years ago. If you make the table big enough to be useful, you cause cache misses. There's a population count instruction in CPUs with SSE4, which by now is almost all x86 machines in active use.
MAC addresses are traditionally 48 bits, but the IEEE is pushing EUI-64, which expands them to 64 bits. Traditionally they were 24 bits of vendor ID, 24 bits of serial number. Address space problems. They also were once fixed in the hardware, but now big shops change them dynamically to make cloud routing ("software defined networking") work.
Somebody has an answer sheet from about 2000.