Tag Archives: career
The “Networking” interview – a few pointers

You’re in a tiny room at Googamazbook and the interviewer comes in, says hi (if you’re lucky), presents themselves (they’re really into doing you a favor) and then starts asking questions. The easy one comes first:

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

Warmed up from the systems interview, you start talking about /etc/hosts and /etc/resolv.conf: name resolution and then the actual connection to the http port. If your knowledge stops here, please do go on reading this text. Or just do go on, maybe I forgot something.

1. Name Resolution

The name resolution protocol is performed by sending an UDP packet to each resolver found in /etc/resolv.conf. The UDP packet has a small header containing:

Continue Reading →

Crazy DevOps interview questions (4)

Note: The first 3 episodes of the interview series can be found here, here and here.


Question 1:

You have the shared document open and the phone rings. The interviewer, at the other end of the line, starts with a thick accent:

 – What does ls * do?

You cannot believe your ears: it sounds easy. Really easy. So you answer in the line of “it lists all the files in the current directory”. The interviewer follows up with one or 2 questions on how it really works and you answer about the star being passed as a parameter to ls and how the binary interprets it in some way that it gets the entire directory walked over and its contents listed. Simple!

Continue Reading →

When there’s no route forward (or so you fear)

Note: This is a text about the project work at one of my previous employments.

Introduction

These days everybody talks about Agile, Automation, DevOps and Continous (whatever), without truly understanding why things have gone in this direction. After all, for many years, a software project had a couple of well-known steps that needed to be followed, like:

  • Full, thorough planning at the very beginning and from time to time, before significant milestones;

  • Development, lots of development behind closed doors;

  • Lots of manual QA work, little automation with some custom-written testing framework written from scratch by one of the developers;

  • Infrequent releases (e.g. every year or even every other year or so); releases were thoroughly prepared and tested, with code freezes for (sometimes) months before the Day.

Even if everybody knows these days that such approach may have been a bad way of doing things, it actually worked for many years because that was the way the world expected things to work. There were many constraints, e.g:

Continue Reading →

Previous Page · Next Page