Note: this text is about Systems Programming on Linux platforms.
This type of interview is focused on finding out what do you know about what happens below the “command line” surface. Down there things can get messier, as processes get created, terminated, the output gets collected, system calls are performed. Things get complicated really fast for the unaware or the unprepared.
Let’s take for example a single command that is being run:
$ ls
This is a classical interview question, asked for more than 15 years now. I’m not sure if anyone still asks it in 2016, but it’s still interesting to see the answer. So, what happens when this is being run? (No, not the file list display).
From the beginning:
So – you got yourself an interview with Googamazbook and you are set on failing it. Or maybe you’re not set but you’re simply not trusting the 99.9+% failure rate that is typical for these companies and you want to be in some sort of control over you failing the interview. Either way, you got to the right place!
1st stage failing
Well, the 1st stage is the screening by the recruiter. This is actually pretty hard to fail if you are conditioned from school, like many of us, to always give the (expected) correct answers. Some people are failing at this stage due to not “speaking the same language” as the current employees of the company, but they are a minority.
So if:
you’re set on failing the recruiter screening;
you got yourself a lot of experience;
you were pretty good with quizzes during the school years:
… it’s basically impossible to fail on this one. Sure, you can make up wrong answers, but that’s just lame. Let’s simply forget about it and go to the next stage.
The original text, published in April 2016, can be found here. Business Insider has relayed the text 4 days ago (link), causing lots of debate. You can find my thoughts below.
First things first – the questions look typical for the recruiter screening stage at any large company. Some people know the answers, others lack the most basic concepts and fail such test from the beginning to its end. The purpose of this screening, at its very core, is to reduce the load on the subsequent “interview layers” – phone interviews with engineers and then on-site interviews. It is simply not economically feasible for any company to have a highly trained engineer administer such test; the engineer’s time simply costs more money, along with the mental wear and the likely alienation that is bound to happen due to the incredibly large percent of unsuitable candidates.
The second purpose of such screening, beyond the technical assesment, is to act early on a possible culture mismatch. Does the candidate speak the same language? No, not if they speak English – the question is: do they use the same words to describe technical concepts? “Knowledge”, in a broad sense, can be expressed in many forms, not all of them useful for everybody out there (e.g. the 0x02 – SYN representation, while undoubtely useful for low level debugging, is of no use during a formal or informal talk, even with an engineer with advanced knowledge of the TCP stack).