Jan 22, 2018
I’d like to share my experience interviewing at GitLab, where I had applied for the role of Senior
CI/CD Developer near the end of 2017 . I went through a questionnaire, a take-home project
and six interviews over the course of three months. Unfortunately, they didn’t move forward with an
offer in the end.
I did not have to sign an NDA, but I am still not going to go too much into the details of the
process so as to not spoil it.
It is important to note that GitLab is very transparent about compensation and processes and they
make most information available in several places, such as:
Having said that, let’s get started.
As with any other company, the first step involved dusting off my resume, firing up
pandoc, my favorite LaTeX toolchain, and producing a nice and clean PDF that I
could upload to their applicant tracking system. I applied for the “Senior Developer,
CI/CD” role on October 9th.
By October 10th, I was told by an HR representative that I was accepted and was sent a questionnaire
with three Ruby questions, three Go questions and five general questions, due within ten days. The
questions were easy and involved a modest amount of coding. I sent my answers back on October 15th,
after working on it over the weekend.
Note that this phase happened at a time when the company was gathering in Crete for their “GitLab
Summit” event, which was happening between October 19th and the 25th. I got a couple of emails from
two different HR representatives reminding me about that.
One Step Forward
On October 27th I got an email from the CI/CD team lead with a couple of questions covering aspects
of the questionnaire. I sent back my answers on October 28th. I didn’t hear anything back until
November 1st, when an HR representative told me that I was invited for a screening call, which I
scheduled for November 7th. The screening call was held by an HR representative which would later
become my main point of contact during the interview process.
After the screening call I was invited to schedule another call with the CI/CD team lead, which
happened on November 14th. Unfortunately, he arrived late to the call, but I had the chance to chat
with another senior developer. Even though we only chatted lightly about technical topics I was
deeply and positively impressed by their attitude, friendliness, and skill set. At the end of the
call we scheduled for another call to happen on Friday 17th.
On Thursday night (November 16th) I was told by my HR contact that we would need to reschedule the
call since a someone from the US wanted to join the call. I was told to book a free slot overlapping
on both team member’s calendars. Being unable to find one, I told my HR contact so and she found me
a slot on November 30th.
I was headed towards my first technical interview.
On November 30th I had a two hours call with both the CI/CD team lead and another high-ranking
employee. I was offered the choice between three topics, after which we would have a brainstorming
session which would be followed by an assignment that I would have to do on my own.
The call went pretty smoothly and, again, I was impressed by the friendliness and in-depth knowledge
of both interviewers. It was a really pleasant experience.
After the call, I duly worked on the assignment and, on December 1st, opened a merge request that
implemented a very basic MVP for the interview topic that I chose. This spurred a fair amount of
activity on the merge request itself and the issue ticket it was linked to, since there seemed to be
some interest from the community in having such feature.
I didn’t hear anything back until December 14th, were I was told that GitLab would like to move
forward with an intermediate-level role, instead of senior. I told them that it was OK by me.
Climbing The Mountain
At this point I was invited to have non-technical calls with many team members moving upwards in the
org chart. I scheduled the first two to happen on December 18th and December 20th. On December 27th,
I was asked to provide some references. My last call was scheduled for December 29th.
These calls weren’t technical and mostly involved questions about my resume.
After the last call I finally had a chance to relax, at least until new year’s. I told myself that
the next call, if any, would be with the CEO at this point, as per their hiring practices.
Ten Steps Back
And here comes the end of our journey. On January 2nd I was told by my HR contact that GitLab
wouldn’t move forward with the application. I was bummed.
When I asked for feedback about my interview I was told that I had strong consultancy and
entrepreneurship experience, and that I was weaker in working at a mid-size product company.
The feedback was totally fair. I co-founded a startup, and my only other work experience is at a
consulting shop. My past work experiences, however, were clearly stated in my resume.
What I found especially frustrating was the fact that I was rejected only at the end of the
interview process, whereas I could have been rejected at the very beginning. Due to their background
requirements I had no chance to join the company from the start.
In the end it all felt like a huge waste of time, both mine and of all the people involved in the
interviews. I seriously hope that the same doesn’t happen to other candidates.
I really enjoyed chatting with everyone I was interviewing with. Everyone there is clearly
motivated, very capable, and friendly. I strongly believe that GitLab is trying to build something
different that will improve the life of developers for the better, and wish them all the best.
As a candidate, I’ll humbly suggest a couple of improvements:
- Keep everyone in the interview process on the same page about candidate’s expectations and
required background. This would prevent a situation like mine. I was essentially rejected from the
very beginning but no one, except the last interviewer, really knew that. Reject me sooner,
don’t waste my time. Or yours.
- Designate a single point of contact between the candidate and HR and let all communications with
the company go through that person. I was contacted by no less than four different HR
representatives. At many points a new person would come up from nowhere and send me an email,
without introduction. Other times I wouldn’t hear back for days with no clear indication of where
I was headed to. It was confusing.
Nov 6, 2017
I’m trying to like Apple Music but I can’t.
I’ve been using Apple Music on and off ever since it first launched at the end of June 2015. It made
sense at the time. I was, and still am, all-in into the Apple ecosystem. Apple Music promised to be
better integrated with my hardware and software than anything else on the market. Also, one less app
to install and one less account to log into. Hooray!
Initially, there were problems. Many of them. Apple Music had just been launched, so they were
expected. iTunes on the Mac and the Music app on the iPhone would often skip songs, stop playing out
of the blue, or take a long time to change tracks (even on a fast and stable WiFi connection). Music
on the iPhone would often tell me that something was wrong, inviting me to retry with a tap. Except
that said tap would never work, only killing the app from the task switcher would “fix” it. I kept
telling myself that it would get better.
After a while, I decided to sell most of my Apple stuff and go back to Android, to see what’s the
world like over there. Let’s call it my mid-life crisis of the Information Age.
Along the ride came the switch from Apple Music to Spotify, which I suddenly could use everywhere:
my Mac, my Nexus 5X, and my GNU/Linux workstation at work. It was pure bliss.
Fast forward two years and I’m fully back to the Apple camp, so here I am, trying Apple Music,
again. Here I am, canceling my Apple Music subscription in favour of Spotify, again.
There are many reasons. The first, and most important, is that the “portals” through which I access
Apple Music (iTunes on the Mac and the Music app on iOS) feel slow and bloated. Search is slow and
only seems to respond to exact queries. Spotify is more lenient and always seems to find the artist
I’m looking for even when I’m misspelling its name. I’m also still experiencing some of the
problems that plagued the service at launch. Spotify is zippy and always amazes me how well it
Siri integration works fine, except when it doesn’t. More often than not, it won’t understand an
artist’s name and starts playing random stuff instead. No Siri for me.
The “For You” section is… well… passable. The AI-generated “My Chill Mix” was always
impressively on point. “My New Music Mix” was just terrible, full of music I would never listen to.
No amount of “loving”, adding, and following artists or tracks seemed to improve the situation.
Again, Spotify’s programmatic suggestions (its “Discover Weekly” playlist) are consistently better.
The dealbreaker for me is that there Is no way to use Apple Music on my work machine. It’s a
powerful Linux workstation with lots of cores and RAM. The kind of work I do can’t be done on macOS.
It can’t be done on Windows, either. A Linux desktop for work is fine and I like it. It’s just
lacking a native iTunes client . Given that all competitors can be used from Linux in
a way or another (usually via a Web interface) I fail to understand why Apple doesn’t have one.
Spotify even went the extra mile and shipped has a native client for Ubuntu!
Apple Music, at this stage, is kind of a “meh” product, bleeding from tens of paper cuts. It’s only
advantage is that it comes built-in with all Macs and iPhones, is better integrated in the Apple
ecosystem, and requires one less app to install and one less login to remember. I would probably
switch back to it if my primary work machines becomes a Mac or Windows workstation where iTunes is
Until then, in the sea of 9,90€ music streaming services, I feel like I’m better served by Spotify.
Jul 23, 2017
I’ve been using Android mobile phones since Eclair (2.1). While the operating system visibly
improved at each iteration, updates were, and still are, a major pain point.
Most non-Nexus and non-Pixel phones don’t get prompt security fixes for the increasingly
bulletins that Google publishes every
Users are also missing out on performance and battery improvements that appear in new Android
releases. Most flagship phones released in 2017 had Android 7.1 at a time when 7.1.2 was readily
available, a six month old release. Lots of budget phones sold in 2017 come out with Android 6.0, a
version that’s more than 18 months old at the time of writing.
Most devices are sold on carrier contracts. Chances are that updates have to go through several
gatekeepers. The first one is Google, then hardware vendors, then phone makers and finally the
carrier itself. Each step requires validation, testing, then more validation, and then more testing.
There’s simply no economic incentive for anyone in this chain (except for Google) to support a phone
after it has been sold. This means that major updates get hugely delayed . More often
than not, this also means that devices are not getting quick security updates, which is worse. The
latest round of security vulnerabilities means that receiving the wrong SMS/MMS or being near the
wrong Wi-Fi or Bluetooth radio could result in a compromised device. People have no control nor
defense against this, besides patching security holes.
In this race to the bottom some manufacturers clearly state that it costs too much to push security
updates on a monthly basis. They prefer to roll them up with major platform updates, but this means
that they are leaving their users unprotected for long stretches of time.
Quoting an article from Ars Technica:
Motorola understands that keeping phones up to date with Android security patches is important to
our customers. We strive to push security patches as quickly as possible. However, because of the
amount of testing and approvals that are necessary to deploy them, it’s difficult to do this on a
monthly basis for all our devices. It is often most efficient for us to bundle security updates in
a scheduled Maintenance Release (MR) or OS upgrade.
The problem, however, is: how do you sell security to users? How do you get them to vote with their
money, the only weapon they have to force vendors to change their attitude? Most people don’t want
to spend 800€ on an iPhone , which is probably the most secure consumer mobile phone
available today. The layperson doesn’t really have a concept of “software updates” and “security”.
Even fellow software engineers don’t seem to grasp or fully appreciate the concept! Most people just
want a cheap smartphone to use SnapChat and WhatsApp, they probably won’t demand security unless
they get hacked en-masse and experience direct economic damage from hacking attempts.
Which means that the burden of keeping users secure lies entirely on Google’s shoulders.
Google recently announced Project Treble,
an initiative to decouple generic parts of the Android operating system from vendor-supplied support
code by, essentially, creating an
With this change, vendors will only need to customize the hardware support layer, assuming the HAL
is well defined and well separated from the rest of the system. This is a nice improvement since,
before Treble, hardware customization usually needed changes spread across the entire operating
However, I’m not confident that this will solve anything at all. With this model, SoC and phone
manufacturers are still responsible for shipping updates and, as we said before, there’s just no
economic incentive for them to update phones. These companies live on razor-thin margins and any
cent saved can be spent surviving in this highly-competitive market.
Even on the high-end (i.e. phones that cost more than 600€) things aren’t that rosier. While
manufacturers may have an easier time updating the low level guts of the operating system let’s not
forget that most players in this space still rely on heavily skinned Android versions such as
TouchWiz, Sense, EMUI, etc. Skins slow down updates as much as adding hardware support and Google
doesn’t have an answer to make that easier, yet.
I strongly believe that the situation won’t improve at all until Google either:
- Starts updating the operating system by itself, bypassing manufacturers and carriers, and letting
them only manage hardware integration and the baseband processor.
- Starts exerting more control over partners (especially phone manufacturers) using access to Google
Play Services as leverage against vendors who don’t, for example, promise to push monthly security
updates to users for at least three years since a phone’s release date. Those failing to do so,
should see access to the Play Store and proprietary Google apps revoked.
I don’t think Google will choose the former, since it goes directly against the very reason that
made Android popular in the first place, and would risk Google’s relationship with hardware partners
(e.g. Samsung) and carriers.
I am more confident that Google will try the latter. We’ll see how this one pans out.