I’m not really used to speak about my job here, but it’s been some time since I had this blog-post idea, and I guess I need to write it down.
When I joined Weborama in 2010 it was as a software engineer, responsible for some backend developments of the advertising platform of the company. It’s been five years this summer that I joined the company and my role evolved a lot since then.
One thing after another I eventually became CTO of Weborama. Of course it didn’t happen in one day and I’d be lying if I told you I had that in mind in 2010. Life really took me by surprise there. I became CTO because the people and the team I worked with allowed me to.
I met wonderful people during those five years, some of them are still working with me today, others don’t, but I really had the impression my role evolved with the team.
When the opportunity of handling the CTO position came, my main concern was to question myself about my ability to deal with the expectations of such a role.
Will I be able to be a good CTO? How do you train for such a position?
Will I cope with the pressure of delivering working releases of and adserver and a DMP while maintaining a good team spirit within the team?
Could I handle crisis situations or manage to keep hiring people at a good pace?
All those questions jumped from everywhere. But the most important one didn’t.
When you build a high-availability platform for a multi-million-euro company, technical challenges are tough and not uncommon. That’s your daily job to deal with them, and to make sure the right people are working on the right priorities.
This is not something a school can teach you, as this kind of role comes with different expectations depending on the company you are working in. But you can deal with it. If you’re motivated enough and focused on your job, you’ll deal with it.
What I really didn’t see coming was the sort of solitude this role brings. You cannot avoid that: the minute you become the manager – the “boss” – of your previously co-workers, you become different to them. You cannot be the same as before, as you are their boss. You are the one that will decide if they get a raise or not, a bonus or not, if that new comer is going to be confirmed as an official employee or not.
No matter how much energy you put into being as fair as possible in such touchy decisions, you’ll always be seen as the one under the authority hat. And nothing you can do will change that, it is a fact.
In one hand, you are expected to be a good manager, and that means making sure everyone in your team is effective and motivated. On the other hand, remaining seen as a friendly manager is an asset you want to keep. But sometimes, those are opposite targets. Either you’ll be “too kind” and your management won’t be strong enough, or you’ll be too severe, and people will start being upset with your decisions, becoming less motivated at the same time.
This is clearly the most difficult challenge of becoming a manager: being able to play with those opposite forces, as if you were trying to mix fire and water.
Finding the right tone just in the middle of a strong and a friendly management seems to be the key. This is not an easy task.
I did my best so far, but I also realize that the more (positive or negative) pressure the company gets, the more expectations you put on the team, the less friendly you become.
I think the real challenge is there: being a good manager and remaining friendly to your team, as much as possible. I strongly believe in the “friendly” management (over the management by fear, that I’ve seen elsewhere), but I start to wonder if it’s even possible to keep such a strategy in place for a long time.
As I was looking for native GTD apps (that’s really what I miss with NirvanaHQ) I ended up visiting RescueTime. OK it has nothing to do with a GTD app, but wait, it’s really worth a look!
The idea is very good and the implementation as well, let’s see what this is all about.
Rescuetime is a service that collects transparently all your activity on your workstations. Don’t be afraid, you control that entirely and we’re speaking about your office workstation, not your smartphone or your private laptop. And if you use the same device for home and work duties, you can define hours when RescueTime logs information and other period of time where it doesn’t.
To do so, all you need to do is to install their program on your desktop and the browser extension on your browser. Of course, if you have more than one device, you can install their software everywhere, all the metrics will be merged nicely.
From this point, you’re all set. After some time (15 minutes is a minimum) you can go to your dashboard and see by yourself how you used your devices.
Did you visit Twitter or Facebook? That’s a “distractive” activity.
Did you use Thunderbird or Outlook? That’s a “communication” activity.
You get the point.
The tool comes with very sane defaults (even for well known websites) but you can very easily classify any unknown activity.
On top of that, you can define objectives like “being productive for at least 5 hours a day” and your dashboard will help you keep track on that.
They also provide a premium version ($9 per month or $72 per year) with interesting features like the “Focus mode” where you choose to get focused for an expected amount of time and during that time you won’t be able to run applications or visit websites that don’t fit the productive category. Very good idea… What about that presentation you need to finish? Focus mode for 2 hours!
That version can also log the amount of time you spend away from your desktop, like… meetings.
Of course using such an app is a massive intrusion to your privacy as everything you do is logged and saved on their websites, but the service is great and if you install that only on your workstation it’s not really an issue, to my opinion.
I’m curious to see my first weekly report and see how much time I spend writing or reading emails…
Well thanks to Rescuetime, I’ll know, apparently, it should be around 30% of my time, according to their stats.
Well, RescueTime, definitely worth a try, the Premium version? Why not giving it a try as well. We’ll see!
WebKeepass is a small Dancer2 web application that exposes a KeePass database with a web frontend. I developed it in order to be able to access my Keepass database from any device, securely.
Although a bit rough on the edges, the project got some users and GitHub watchers (apparently it fills a gap for other people than myself) and I started receiving some feature requests and bug reports.
When it comes to interviewing software engineers it’s quite of a challenge to come up with a good interview plan. It’s also very important to test the applicant when you’re hiring programmers, good presentation skills and nice words can deceive a lot. I’ve seen graduates from prestigious schools coming with an impressive CV, a very nice way of describing their past experiences and still, they weren’t able to write a “for” loop with a simple conditional branching structure.
I came across this article recently and I read there so many things wrong I couldn’t resist to write a follow-up.
The article starts by saying we (the reader) are wrong about technical interviews. The assumption is quite big : everyone is wrong except the author.
But what really puzzles me is more about the ideas rather than the wording.
The Fizz Buzz test
Back to the Fizz Buzz test, the author says it’s just about testing the ability to manipulate the modulo operator. This is utterly wrong.
That test is very good to see if the applicant is able to write a for loop with an if-elsif-else switch. And more importantly, they must be able to do that in less than 5 minutes.
The time constraint is very important. I personally use this test (or variants) as a preliminary step to my “programming” test.
If more than five minutes are needed, or if there are mistakes (it happens a lot, surprisingly, even on a simple problem like “Fizz buzz”), then I know the candidate isn’t able to think easily with basic code structures in mind.
Common mistakes are:
the variable used with the modulo operator is the parameter of the function, not the one from the for loop
the for loop is simply forgotten (only an if-then-else structure, no iteration at all!)
the conditional statements are badly organized and the code does not work
But even if the candidate manages to implement a fizzbuzz(x) function without errors, if it took 15 minutes or more, something else is wrong, it took too much effort. The ability to implement that function in few minutes is a very good metric about the programmer’s skills.
So no, fizz buzz is not about the modulo operator, at all. It’s about the very basic skills one must have to apply to a programmer role.
What about the whiteboard?
In the article, the author advises us not to ask people to write code to the whiteboard, because it’s too far from the reality and “you are asking them to write code under time pressure, with somebody watching“. Yes. exactly, that’s the point.
Of course in real life, nobody writes a code sample on a whiteboard, but the ability to do so, under a bit of pressure, is a very good way to see how the person manages to handle a bit of stress, and how natural it is for them to think code. You can compare that to a musician: if you’re able to play your guitar in your room, alone, it’s not the same thing as playing it on stage, in front of many people watching. It’s very similar. If you need a very quiet and peaceful mood to be able to code something simple, then you will have trouble working in a team with business expectations based on your code. That’s a no-brainer.
The whiteboard also brings something very interesting to the table: it leaves the applicant alone with only what he deeply knows about programming. There is no way to escape to a scheme of trial-and-error with the code sample they’re writing, it forces the person to compile the code they write in their mind. And if you’re able to write a functional code sample on a whiteboard, it’ll be piece of cake to do so with your computer.
It’s not surprising if Google, where you can find a lot of brilliant engineers, use this interviewing technique intensively: applicants who are selected to be invited on-site, pass no less than 5 consecutive interviews, all of them “on the whiteboard”.
You want your mind to be in the general “mode” of problem solving on whiteboards. If you can do it on a whiteboard, every other medium (laptop, shared network document, whatever) is a cakewalk. So plan for the whiteboard.
The author also thinks that Whiteboard and coding interviews also routinely ask people to re-implement some common solution or low-level data structure. This is the opposite of good engineering. I’m surprised he thinks the medium (the whiteboard) is the same thing as the message (the question asked).
If I use a whiteboard to run my interviews, it doesn’t mean I’ll ask the same questions as another person doing an interview on white board. And about “good engineering skills“, it’s perfectly possible to use a whiteboard to get a feeling of them, for instance by using the very good problems of the “Programming Pearls” book.
I do that all the time, at the very end of the interview (if the FizzBuzz test was passed, no need to go there if not).
About the degrees and certifications
Although I strongly disagree with the previous items, some points make sense. I agree with the author on the fact that a degree as a very low value itself. It’s possible to see people with a good degree completely unable to deal with basic problems, or unable to write a for loop. Surprinsingly, you can have a degree in computer science without being able to construc an if-else structure…
On the other side, there are brilliant people without a degree, so I don’t give a lot of credit to the degrees myself, it’s just a low signal to consider. The technical interview has much more credit to evaluate the real skills and knowledge.
Programming language skills?
Interviewing on the skills about a specific programming language appears to be a trap. We did that in the begining but we changed our strategy. If you organize your interview (and the job offers) around one unique programming language and how effective the programmer is with it, you’ll end up with two issues:
you narrow the scope of people you can reach to those “experts”
you tie your vision to a programming language
If you want to build a company around experts of a specific language, you can, but it’s a bet you do for the future, on that language, its community and its ability to evolve well in time with your products and your industry ecosystem. It’s not necessary a bad strategy, but it brings limitations.
If on the other hand, you open your job positions to “Good Software Engineers” and you stop thinking about “the programming language”, you open a lot of doors. Your job positions become instantly more open, and you can meet people very talented, who don’t know yet your programming language but who will be able to learn quickly.
The other benefit of that approach is that if at some point you want to embrace a new technology, designed for a new language, you already have people able to adapt to that situation. This is maybe not the case if the team is built around some language experts; they might be reluctant to do the switch, more likely because they love programming with their favorite language. Which is a natural feeling when you’ve been working in a specific way for many years.
A programming language is a way to implement a solution to a problem, it should not be a purpose, it’s a tool.
Besides the points where I disagree, the good thing about this article is that it shows how difficult it can be to interview engineers, when you want to identify the right people for your team.
It’s really true it’s quite hard. I’ve been doing engineer interviews for some years now and I clearly learned a lot. My first interviews were very bad, if I compare them to those I do today. In the very first ones, I wasn’t even doing technical tests or any kind of evaluation of the actual skills of the person. Now I’m armed with a quite dense cheat sheet of questions/problems, organized by topics, where I can pick stuff during the interview.
Depending on the reactions of the candidate, I can adapt my questions to harder or easier topics in order to get a good feeling after the hour we spent together.
The only part that is missing from my interview plan, is how to evaluate the person’s state of mind, or how he or she would fit well in the team’s spirit. Would the person enjoy working with us, and would the rest of team feel the same about that new person? That’s probably the most important thing to evaluate, and sadly, it’s maybe the hardest thing to picture during an interview.
At the end of the day, when we hire someone, we’re trying to build a team, and teams are effective if the people inside work well together.
Here is the real challenge, beyond finding skilled people, it’s finding skilled people who can work together, and as your team grows, it’s more and more of a challenge.