A nightmare of a day at work.

We have a major release planned for 17:00. Four hours before release, key functionality that we really, really want to get out to customers is still not release-ready.

The web site is down already when I get into the office at 8. Infrastructure issues at our hosting provider. At 15:40 the application, the thing our customers are paying for and the thing we want to upgrade, also goes down.

At this time I go out for a long walk to clear my head of all the frustration, and take some photos of the neighbourhood.

(When I come back, all the servers are still down. We take a pizza break and start preparing ourselves mentally for having to cancel the release that we’ve been planning for since before summer. At the very last moment, when we are minutes away from cancelling, the servers come back online and we forge ahead after all.)


Our developer team took a day off from ordinary work and had a “dev day” with a few discussions but mostly with coding for fun together.


Took the camera to work. This is our bi-weekly Monday morning combined breakfast/company meeting/demo, in what is normally our lunch room but also serves as a meeting room for the largest meetings.

Recruitment-related tasks have been filling most of my days at work since January. Now I am finally seeing a glimpse of light at the end of the tunnel. We are close to signing a contract with a good back end developer, and today for the first time we had a really promising candidate for the front end role.

By now I have a pretty solid and stable process worked out. First I read their CV and/or cover letter, and ask for clarification where I their background really seems to not fit our needs. Well over half of the candidates get discarded at this stage – surprisingly many candidates seem to apply for any job that seems even remotely related to their skills, and don’t hesitate to apply for jobs that they are clearly under-qualified for.

Next I ask them to do a coding task at home, at their own pace. After this we have a brief phone interview. I used to do it the other way round, because I didn’t want to do give them unnecessary work – the task takes a couple of hours to do at least, whereas a phone interview is no more than 30–40 minutes. But it turned out that a lot of people who sounded knowledgeable on the phone failed the coding task, so it ended up wasting a lot of my time instead. And since I get to decide, I’d rather have them waste their time, not mine. The coding task not only filters out the candidates who can talk but not do – it also gives us something concrete to discuss during the phone interview, and therefore makes the interview much more effective.

Now the funnel works quite well. Occasionally I say yes to someone who I am unsure about, and thus far these candidates have always disappointed in the next round. So if the candidate doesn’t seem to have enough relevant experience, they don’t do well on the coding task. And the ones whose coding task does not impress don’t make a better impression on the phone.

All the coding tasks until now have been sort of mediocre, “good enough” at best. We’ve been trying to weigh them against each other but never really come to any firm conclusions. Is one kind of mediocrity better than another? What’s worse, stupid variable naming or badly organized code? How bad is too bad?

The one we got today stood head and shoulders above all the previous ones, and the interesting thing was that this time there was no discussion, no hemming and hawing. The moment we saw the code it was obvious to all those involved that this one was in a completely different league from the others. Distinguishing a really good solution from a mediocre one is so much easier than comparing two mediocre ones. Even if we for some reason end up not hiring this guy, he has at least given us a yardstick for evaluating future candidates.

Another observation we made today was that the good front end developers we’ve met (including those in our team) are all ex back end developers. In other words, they are developers who have chosen to specialize in front end work. The ones who come from the other direction – the designers, the web developers – lack the necessary fundamental development skills. Their solution may work but just it’s like a house of straw: you can see at a glance that it is structurally weak. They don’t build, they hack.

PS: I just counted: I have received 43 applications for this job, reviewed 13 coding tasks, had 10 phone interviews and 2 face-to-face interviews (with 2 more already booked).

This week I have spent almost all my time thinking about recruitment ads, CVs, coding tasks, phone interviews and other such stuff. It is mostly not fun, and sometimes downright depressing. The wheat is there but buried in lots of chaff. To top it all off, one of the candidates that I (politely) rejected has become abusive and is harassing the company about it. Oh how I am looking forward to the day when this process is finished and we have our new colleagues with us… and then of course I will soon start it all over again.

We had a team “conference” yesterday. First we talked.

Then we had a nice dinner.

At work I continue to spend a lot of my time on trying to recruit a front-end developer. And I continue to be surprised by how low-quality many of the applications are. It is very easy to be above average in this process because the average is so atrocious. It makes me realize that in any reasonable job market, short of a total collapse in IT spending, I am always going to find a good job, just because I don’t produce crap.

One key part of our recruitment process is a coding task. I normally send it out before booking an interview, because it weeds out the candidates whose technical skills are clearly not sufficient for the job. It takes me less time to judge someone’s code than to do a full interview.

You’d think that in a situation like this, people would send me the absolute best that they can do (within reason). And instead I get crap. Lack of technical skill or experience is one thing, and just means that this is not the right job for them. But lack of care really has no excuse.

Sloppy JavaScript code with missing semicolons. Code that is indented at random and has random blocks of blank lines interspersed here and there. If/else blocks that, upon close reading, turn out to contain identical code, except for whitespace.

Also, not a single candidate has reflected upon the fact that I have many submissions to look through. I would immediately be incline to judge more positively a candidate who named the file with their submission in a way that would help me tell it apart from all the others. Instead they all name them task.zip, reqtest.rar, servicejson.zip, JsonTask.rar, WS.rar, WebServiceApplication.zip, etc.

Rant over.

PS: On the plus side, a few of the candidates have actually hosted their solution on their own server and just sent me a URL, which is a very nice way to avoid the file naming problem completely.

(See also: Interviewing for a developer job at ReQtest.)

Yesterday a reader commented on my old post about Excel VBA interview questions. As I am, again, spending a lot of my time trying to recruit another developer, I thought I’d tell you about what my current interview plan looks like.

What we’re looking for is a reasonably senior web developer. We’re a small software company with just a handful of developers, so we need someone who can pull their own weight, with no hand-holding or detailed management. Everyone is expected to not just code but also contribute meaningfully to discussions about design and architecture. They also need to share our values and mindset – to value code quality, maintainable code, good design.

The interview is complemented by a coding task, where I email the candidate a 1-page specification for an application and evaluate the code they send back. I therefore spend very little of the interview talking about detailed technical matters. The interview is for me to judge their aptitude and attitude at a higher level.

This is not an interview script. I wouldn’t ask these questions top to bottom. It’s more of a checklist for areas that I try to cover during an interview. This is also not a prioritized list.

For the rest of this post, “you” refers to the candidate.


1. Fit

What kind of a job are you looking for? What kind of company would you like to work for? What is important to you in your work? Why are you looking for a new job?

What I’m trying to establish here is whether the candidate would fit our firm. If they are looking for a fast-paced competitive environment, or a firm with international opportunities, they’re not for us.

What would you like to be doing in 5 years’ time? What do you enjoy most about programming? Have you been involved in requirements or testing in your previous projects?

This is to detect the wannabe project managers and business analysts, and people who are aiming for a managerial role. Nothing wrong with those, but we won’t be able to offer them a meaningful career path in our company. This is also to detect the pure programmers who have no interest in anything outside of code, who will consider testing and requirements work and usability studies to be “not their job”.

2. Passion, learning, interest

How do you keep up with current topics within the industry? Do you read any books? Blogs? Do you do any programming in your spare time? What’s your favourite tool?

Here I try to figure out whether programming is “just a job” for them, or whether they are truly interested in and passionate about writing software. It isn’t necessary for the candidate to do all of this, to read books and blogs and have hobby projects – but if they do none, it’s a great big warning sign.

3. Technical insight, critical thinking, big picture thinking

Explain the purpose of a recent project you worked on. Explain the design and the architecture. What choices and alternatives were considered? Why did you make the choices you made? What would you do differently if you had to do it again?

This separates the “drones”, the passive followers from the active minds. Even if the candidate wasn’t in charge of the project they describe, they should be aware of design choices and trade-offs.

Did you use an Agile process? What were the advantages and disadvantages? Did you use test-driven development, or unit tests or automated tests of any kind? How did that work?

If in this day and age the candidate has nothing to say about unit testing, they are not for us.

4. Some technical questions

This is a bit of a smorgasbord; I pick the areas that are relevant for the candidate’s area of strength. SQL and OOP for back-end developers and JavaScript and CSS for front-end candidates.

The home coding task tests general programming skills. Here I focus more on the specific technologies we work with. This whole area also ties in with #3, i.e. their ability to make trade-offs and informed choices.

OOP: Explain to me a design pattern that you have found useful. Why? Explain to me the purpose of the Single Responsibility Principle.

ASP.NET: Explain to me some different ways to save state between page requests. What are the pros and cons of each one? Which ones did you use in your last project? Why?

SQL: I give them an example table and ask them to write or dictate to me some simple queries against that table.

JavaScript: Explain callbacks, and why they are useful. Explain closures, and why they are useful.

CSS: Tell me about what you would use to build a page. Divs or tables? Why? How can you position a div – how can you center it, put it in a specific position on the page, etc.

5. Leadership and self-leadership

What was your role in the project? What were you responsible for? What are your weaknesses?

We need people with drive and initiative, who are able and willing to take on significant responsibility. The weaknesses question is mostly a basic indicator of self-insight.

Do you know any good developers in the Stockholm area? Send them to me!

ReQtest, the company I work for, is looking to add two more developers to our team, one for front-end work and one for the back-end. The foundation for our application is ASP.NET and C#. On top of that the front-end guy needs great JavaScript and CSS skills; the back-end developer needs experience of database development.

We’re a small and growing company so we offer lots of responsibility and variety in the daily work, and a say in just about all matters regarding both the product and the company. We use an Agile development methodology, and we value code quality and usability highly. It’s a great place to work.

Read more on monster.se: front-end developer, back-end developer.

Every year, for the past 10+ years, I have looked back at the year that passed and summed up the major changes in my life and any particular achievements. There have been career shifts, getting married and giving birth, climbing mountains, moving from one country to another, learning new technologies, taking up new hobbies etc.

This year I look back and I can’t point to anything memorable that I have achieved, learned, or experienced. I do useful work, but nothing I do is remarkable either from the company’s point of view or for me personally. I cannot say that I have moved forward from where I was standing the same time last year. And last year was equally dull careerwise, but at least there was the birth of Adrian to remember.

Something has to change in 2012.