The situation at work is spinning out of control.

We got a new CEO a couple of months ago. Various workshops about our processes and practises followed, and were welcomed by the team, because we knew things needed to change. Agreement was easier to find in some questions than in others, but in general, we worked until we agreed on key points.

Now I feel that the development process has effectively been hijacked by the CEO. The development teams no longer have much say about important parts of it.

Previously we had workshops. Now we have meetings where we are told what to do. We sigh with resignation, and he does not seem to even notice.

We do not have agile self-organising teams any more. We have top-down planning and scheduling instead. We don’t really even have teams any more – just a bucket of people. (A “bucket” being the technical term for “an unordered collection of weakly related items”.)

The chances that I will still want to be with the company in, say, half a year’s time are decreasing by the day. Currently I’d put them at 10%. This thought actually feels quite liberating.

So I went to the gym and took out my frustration on the kettlebells. I cycled to and from work to tire myself out, so I can sleep at night. When I got home, I found peace in photography again, and then attacked some of the more stubborn large rocks in the ditch I’m digging.


Today is release day at work. The release responsibility rotates so most developers are reasonably proficient in pressing the right buttons, and it wasn’t my turn this time. I normally stay in the office for the release anyway, especially if the developer pressing the buttons is a junior one, because I feel ultimately responsible. Today I couldn’t stay late, so I logged in from home instead, after picking up the kids from school.

It turns out the kids are surprisingly good at entertaining themselves and doing things together if they really, really don’t have the alternative of hanging around an adult. They spent a good long while playing with kinetic sand, and they even cleaned it all up after themselves.


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.