This is meant to be a text about following your passion. Some people set out to save the world, while others go for seemingly simpler things, like popping green pigs. Don’t get me wrong: it’s not about the purpose per se, but about the way you get there. It always comes down to work, and a lot of it.

Looking at the screenshot below, you could easily conclude that at some point I became very, very efficient in the pig-popping business. After all, some of these golden eggs only unlock after winning 3 stars in around 60 different levels.

The long interview day is almost over. Googamazbook has drawn out the best and the worst of you (well, neither, but I’m trying to sneak in some literature). The last interviewer walks in, smirks, and says:

Time for the easy interview, heh?

You have every reason to worry that you’re one step from failure. Why didn’t you spend the day by the pool in the basement of that many-starred hotel they booked for you? Without further ado, the questions start coming.

You’re sitting in a tiny room at Googamazbook. The interviewer comes in, says hi (if you’re lucky), introduces themselves (they act like they’re doing you a favor) and starts with what seems like an easy question:

What happens when you run telnet www.brainware.ro 80? Please go through all the layers.

Warmed up by the systems interview pointers, you start with /etc/hosts and /etc/resolv.conf: name resolution first, then the actual connection to the HTTP port. If your knowledge stops there, keep reading. If it doesn’t, keep reading anyway, in case something was missed.

Note: This is the fourth article of the series. The others are: part 1, part 2 and part 3.

You have a shared document open when the phone rings. The interviewer, speaking with a thick accent, asks:

“What does ls * do?”

It sounds far too easy to be true. You say it lists all the files in the current directory. The interviewer asks a couple of follow-ups about how it works, and you explain that the star is passed to ls as an argument, which somehow makes the binary walk the whole directory and print its contents. Simple!

Note: This article is about Systems Programming on Linux platforms.

This kind of interview checks what you know about what happens beneath the command-line surface. Down there, processes are created and terminated, output is collected, and system calls are made. Things get complicated quickly for anyone who is unprepared.

$ ls

This classic interview question has been asked for more than 15 years. It may not come up much anymore (as of 2016), but the answer is still instructive. The question is not about the file listing that appears on screen, but about everything that happens to produce it.

CloudFormation is Amazon Web Services’ core tool for expressing infrastructure as code. Infrastructure is described in either JSON or YAML (the keywords are nearly identical), and a template designer can help assemble resources and their dependencies. The specifics of each resource still have to be written out by hand.

From what I’ve seen, there is no limit on the kinds of resources you can define. Every resource type AWS offers can be coded, created and provisioned. You can set an explicit creation order (e.g. resource A before resource B) on top of the implicit order CloudFormation works out itself (e.g. an IAM role attached to an EC2 instance is always created first). Rollback is clean too: deleting a stack removes everything the stack created, and nothing is left behind.

Note: This is a reflection on project work done at one of my previous employers, covering a period from late 2000s to early 2010s.

Agile, automation, DevOps and “continuous everything” are on everyone’s lips these days, yet very few people stop to ask why the industry moved this way. For many years, software projects followed a then- familiar routine:

Note: You can find my comments on the similar event held in 2015 here.

Another year, another AWS event. The venue changed and more speakers were brought in, but unfortunately they were of lower quality than Sebastien Stormacq, the sole speaker in 2015. Registration doubled this year, with roughly 500 people queuing for the early-morning check-in.

The biggest change from last year was that the content was split into two tracks, a “technical” room and a “business” room, each with their own focus.

So you’ve landed this incoming interview with Googamazbook, and you’re determined to fail it. Or maybe you’re not determined, you just don’t trust the 99.9%+ rejection rate these companies are known for and would like some say in how you fail. Either way, you’re in the right place.

The recruiter screening is surprisingly hard to fail, especially if school had trained you to give the expected, correct answers. Some people do stumble here because they don’t “speak the same language” as the company’s current employees, but they’re a minority.

The original post, published in April 2016, is available here (original blog post by Pierre Gauthier). Business Insider had recently picked it up (link) and sparked a lot of debate. My thoughts are below.

First, the questions are typical of a recruiter screening stage at any large company. Some candidates know the answers, while others lack even the basic concepts and struggle through the whole test. At its core, the screening exists to reduce the “load” on later “interview layers”: phone interviews with engineers, followed by on-site interviews. No company can afford to have a highly trained engineer run this kind of test. Engineer time is expensive, it takes a mental toll, and it is likely to breed frustration given how large a share of candidates turn out to be unsuitable.