In which I interview so you don’t have to

Posted on 2016-03-15 by Graham

Describing job interviews for technical roles in the software industry to people who have left or have always been outside the software industry requires two things: patience on the part of the one doing the describing, and the ability for the listener to take a joke. Over the last twelve years I have taken countless job interviews so that you don’t have to. Here’s what I’ve found: presented as a guide to running the average software developer interview. As with all descriptions of mediocrity, you should treat this as best practice.

[Be clear on this: not all interviews are like this. But this is an expectable baseline, derived from experience.]

Person Specification

The ideal candidate will be rich. We’re going to put them through hours – maybe even days – of tests, interviews, meetings, and “informal chats” that they’d better be on best behaviour for anyway. They need to be able to afford taking that time away from work, friends, other opportunities, so they’d better be rich.

That multiple-hour interview process means that they’d better be desperate for a job too. As you’ll find out in the section on our process, we pride ourselves on not giving away too much. We’re not selling our company to you, because we know we’re offering the chance to do what you’ve always wanted: sit in our open plan office space next to our own particular loud crisp-eater muttering at Eclipse.

The ability to go without food is desirable too. Even if a stage of the interview is planned to take so long that it would go over lunch, and even though we might put a break for lunch in, we might also forget to do any catering. Computers don’t need food and programmers are sort of like computers, we heard. We actually occasionally do feed our staff, and advertise this as a perk.

Our Process

The first thing we want to check is whether you can solve logical problems. We don’t actually need you to solve logical problems, after all, that’s what the computers are for. But we’ll give you an aptitude/basic reasoning test anyway [yes, although it’s no longer the 1960s and we aren’t IBM, this is still common if not universal].

The reasoning test is there to weed out people who didn’t have the same education as us, or were raised speaking a different language, or in a different culture. Empathy is hard, and to avoid unduly stressing our staff we want to make sure that their colleagues are as similar to them as possible. Additionally the hour you’ll take going through this test is an hour we don’t have to make eye contact or conversation with you: empathy is hard.

To be honest we have no idea what this test means or how to interpret its results. Everybody before you went through this test, and they’d raise merry hell if we “lowered the bar” by removing it now. As a holacracy/meritocracy/hypocrisy/this week’s organisational behaviour buzzword, we empower our employees to not see any changes that might raise a small amount of discomfort.

So after that test, depending on the seniority of the position and the candidate’s experience, we’ll…no, not really. We did nearly keep a straight face through that sentence though. In fact we didn’t read your CV except to find out whether the keywords that describe the problems we have right now and the solutions we have chosen last week appear. We didn’t read your GitHub/Lanyrd/Bitbucket profiles either, except to check that you have them so we know how much free work to expect out of you in addition to the paid stuff. Our project management system works on the Pareto Principle: 80 hours a week on our stuff, 20 hours a week on open source stuff that we can co-opt.

The next stage in the process is actually the same for everybody: a basic programming test to find out whether you even know what a computer is. We don’t care that you’re [glances at CV] Grace Hopper, we still don’t believe that you can reverse a linked list. None of our employees has ever had to reverse a linked list on the job, and we’d fire them if they did reverse a linked list on the job because there are libraries for that.

Now we’ll come onto the technical interview: a cross-examination by a panel of between one and twelve [not joking] people who have, or have had, a word like “engineer” in their job description at some point. These people are tasked with finding out whether you’ve solved the same problems in your career as they have in theirs. If you haven’t, you might not be clever enough. If you have, then what new experiences are you bringing to the table?

By the way, our flexibility on your technical skills will go down as you become more experienced. We appreciate that new grads might not have used our tools/frameworks/technology and are willing to train them, but if you have more than six months’ experience with Java we’re going to call you a Java developer and only consider you for Java roles.

After all of that, it’s still possible that you might have somehow snuck through the system despite not going to the same university or belonging to the same society as the founder. We can’t really quantify the idea of “culture fit” but that’s what we’re examining in the next part of the process and we’ll know it when we don’t see it.

The Offer

You’ll get a phone call from us while you’re in the bath. We’ll outline the position, pay and (unless this is an American company and there isn’t any) holiday provision. You then have two seconds in which to reply, with either “Yes” or whatever the other one is. You may have other irons in the fire but of course you’ll want to drop all of those when we tell you about the parking space we’ve already allocated for you [This has happened. I don’t have a car.].

The Job

You will be working with a team of people who all went through that same interview and decided they wanted to work in our environment. We will leave it to you to decide what that means.

The Alternative

There are some less…scientific…approaches to hiring that involve using the candidate’s stated and visible experience to have a conversation about what they’ve done, how they do and don’t like to work, how they’ve responded to success and failure, and whether the challenges they would like to see in their career match up with the environment we’re able to provide. While that sounds like quite a pleasant experience for everybody involved we fail to see how it could possibly translate into discovering whether we want to work with you or vice versa.

Posted in advancement of the self, Business | 1 Comment

Turn it off and back on again

Posted on 2016-03-14 by Graham

I’m now six months into what I expected to be about a year out of working in technology, and I’m starting to think about what comes next and trying to make it happen. The difficulty I have is that it’s hard to explain what I’m looking for in a way that makes sense to those that are hiring, or that I can summarise in a search term for job sites. I’m considering running a company again to do all this myself, but that doesn’t obviate the problem, I still need to be able to describe this to potential clients and explain why they would want to buy one.

The difficulty comes from being a people person. I listen to people, I talk to people, I get people to talk to other people, I learn from people, I teach people, I perform for people, I watch people, I read what people have to say, and I write for people. And I happen to want to do that for money in the software industry, but if you tell that to a hiring manager on a software team you’ll get a blank stare followed by “um, but how much have you used MongoDB from Scala in your last job?”. You don’t need to try this yourself, I have done it. This is what happens.

I don’t mind much what technology I use, as long as we’re using it because it helps to address the problems we or our customers have rather than because a developer threw a strop if they weren’t going to be allowed to rewrite everything that already works well in NodeCaml. I care about understanding and solving the problems people have, and about understanding the people who have those problems. “I think we should use this” is not fine. “I think we should use this because” is perfectly fine. “We’re a $VENDOR shop” is probably not fine.

So the problem I have is that the job I know how to apply for and get is “programmer” (these days with some highfalutin prefix that really comes down to “better paid”), but that usually comes with some expectation to focus on the programming, and leave all the gloopy soft stuff like what programming should be done and whether it’s a good idea to do it now to other people. What I want to be doing is (being paid for) the gloopy soft stuff like making programmers into better programmers, working out what programming should be done (if any) and whether it’s a good idea to do it now, helping programmers to understand the people they’re helping, and helping the people being helped by programmers to understand the programmers, with the programming itself being a context not a focus. I have no idea how to explain that succinctly to people who might want to hire one of those, nor how to find people who might want to hire one of those.

Practically, based on what I’ve experienced about my own health and its relationship with my work, I also need to be realistic about where and when I work. That’s from or within cycling distance of home (around Leamington Spa, Warwick, Kenilworth and Coventry), from usual working hours my own timezone. If your company is in a different timezone and supports remote work, that’s great, but if you need me to work from your timezone then it’s not great. In fact, you don’t support remote work, you just support local employees who don’t always come into the office.

If you are someone who wants one of those, know someone who wants one of those, or know how to describe one of those succinctly, please do help me out. Based on the last time I tried this, here’s a couple of lists:

Things I’ve never done, but would

These aren’t necessarily things my next job must have, and aren’t all even work-related, but are things that I would take the opportunity to do.

  • Work in a field on a farm. Preferably in control of a tractor.
  • Have a job title that begins with the letters ‘C’ or ‘D’ (I managed ‘Q’ a while back).
  • Spend lots of time supporting the Free Software Definition
  • Include going to lunch with each other employee in the company in my responsibilities.
  • Visit Iceland.

Things I don’t like

These are the things I would try to avoid.

  • I still seriously hate raw celery.
  • Client work, in those cases where we don’t all really think that the client is doing something important.
  • “Rock star” programmers, and people who hire them.
Posted in advancement of the self, whatevs | 2 Comments

New book: APPosite Concerns

Posted on 2016-01-04 by Graham

Back when I published APPropriate Behaviour, I expected it to be the first in a trilogy. Today, the second part, APPosite Concerns, is available.

APPosite Concerns is a compendium of posts from this blog, going back over the current decade. The main topics covered are being a programmer, designing software, thinking about software and computer systems, and software freedom. I hope you enjoy it, find it useful, or maybe even both.

Posted in books | Leave a comment

Clown Trousers

Posted on 2015-12-21 by Graham

An indirect side effect of stopping programming is that none of my trousers fit any more.

People who like to explain things before they have all the facts (or “programmers” as we sometimes call them) will justify this observation by pointing out that I have more time for exercise now. I do, but I don’t use it. While working at Facebook I walked six miles each day as part of my commute and worked at a variable-height desk; I spent a lot of time walking and standing.

When I began my gap year, I put some effort into running every day. That didn’t last long. I still stand a lot to play musical instruments, but am significantly less active now that I’m 8kg lighter than programmer Graham.

Looking at videos of programmer me, I just see an obese, tired guy surviving on caffeine, sugar snacks and three big meals a day as he lurched between commuting trips, flights abroad, conference talks and infrequent visits to bed. Peak Graham (weight for weight) came in June, as attested by the video of my AltConf talk, I have no idea what I’m doing.

It turns out I had no idea what I was doing to myself either. But now that I’m not doing it, the historical record that is my wardrobe tells me I’m healthier than I have been in over five years.

You may not need hipster silicon valley nutritional engineering sludge. You may not need an extra hour in the day to fit in a run and a shower. You may not need to drop a few hundred quid on a watch that also reminds you to stand up. You might just need to discover what you’re doing wrong, and not do it like that.

Posted in advancement of the self, whatevs | 3 Comments

New project: a dance a day

Posted on 2015-11-30 by Graham

Starting tomorrow, A Dance A Day will, as its name suggests, feature a new dance tune every day, mostly taken from the English country dance tradition.

Posted in meta-waffle | Leave a comment

The Principled Programmer

Posted on 2015-11-19 by Graham

[Note: this post represents the notes made for my talk at iOS Dev UK 2014. As far as I’m aware, the talk isn’t available on the tubes.]

The Principled Programmer

The first thing to be aware of is that this post is not about my
principles. It’s sort-of about your principles, in a way.

On dichotomies

Let’s look at two games. You may not have heard of Chaturanga (unless
you practice yoga, but I’m talking about a different Chaturanga), but
it’s the ancient game that eventually evolved into Chess.

You may not have heard of Nard either, but it’s a very different game
that grew up into Backgammon. There’s a creation myth surrounding
these two games, that says they were invented at the same time. Some
leader thousands of years ago wanted two games; one a game of skill
and the other a game of chance.

The thing is, you can lose at chess by chance: if you happen to be
having an off day and miss a key move that you’d often
make. Similarly, you can lose at backgammon through lack of skill: by
choosing to move the wrong pieces.

We were presented with two options: skill (chaturanga) and not-skill
(nard). However, the games do not actually represent pure states of
the two concepts; they’re more like a quantum system where the
real-world states can be superpositions of the mathematically “pure”
states.

All of this means that we can’t ignore states in-between the two
poles. Such ignorance has a name in the world of critical analysis:
the fallacy of the excluded
middle.

That is not the situation we have in bivalent logic, including the
mathematical Boolean formulation frequently used to model what’s going
on in computers. This has the law of the excluded
middle, which
says that a proposition must either be true or false.

In this case, the fact is that the two propositions (you are playing a
game of skill, or you are playing a game of chance) do not exactly
match the two real possibilities (you are playing chaturanga, or you
are playing nard). There’s a continuum possibility (you are using some
skill and some chance), but a false dichotomy is proposed by the
presentation in terms of the games.

On rules

The existence of a rule allows us to form a bivalent predicate: your
action is consistent with the rule. That statement can either be true
or false, and the middle is excluded.

This means we have the possibility for the same confusion that we had
with the games: compliance with the rule may be bivalent, but what’s
going on in reality is more complicated. We might accidentally exclude
the middle when it actually contains something useful. Obviously that
useful thing would not be in compliance with the rule. So you can
think about a rule like this: a statement is a rule when you can
imagine contraventions of the statement that are of no different value
than observances of the statement. Style guides are like this: you can
imagine a position that contravenes the rules of your style guide
that is of no lesser or greater value: following another style
guide.

Of course, the value of a style guide comes not from the choice of
style, but from the consistency derived from always adhering to the
rule. It doesn’t matter whether you drive on the left or the right of
the road, as long as everybody chooses the same side.

One famous collection of rules in software
engineering is Extreme Programming. Kent Beck described hearing or
reading about various things that were supposed to be good ideas in
programming, so he turned them up to eleven to see what would
happen. Here are some of the rules.

  • User stories are written. It’s easy to imagine (or recall)
    situations in which we write software without writing user stories:
    perhaps where we have formal specifications, or tacit understandings
    of the requirements. So that’s definitely a rule.

  • All production code is pair programmed. The converse – not all
    production code is pair programmed – poses no problem. We can imagine that the two conditions are different, and that we might want to choose one over another.

Rules serve two useful functions, of which I shall introduce one
now. They’re great for beginners, who can use them to build a scaffold
in which to place their small-scale, disjoint bits of knowledge. Those
bits of knowledge do not yet support each other, but they do not need
to as the rules tell us what we need to apply in each situation.

The software engineering platypus

Having realised that our rules are only letting us see small pieces of
the picture, we try to scale them up to cover wider
situations. There’s not really any problem with doing that. But we can
get into trouble if we take it too far, because we can come up with
rules that are impossible to violate.

A platitude, then, is a statement so broad that its converse cannot be
contemplated, or is absurd. Where a rule can be violated without
hardship, a platitude cannot be violated at all – or at least not
sensibly.

The problem with platitudes is that because we cannot violate them,
they can excuse any practice. “I write clean code”: OK, but I don’t
believe I know anybody who deliberately writes dirty code. “This
decision was pragmatic”: does that mean any other option would be
dogmatic? But isn’t “always be pragmatic” itself dogma?

Platitudes can easily sweep through a community because it’s
impossible to argue against them. So we have the software
craftsmanship manifesto, which values:

  • A Community of Professionals. As any interaction
    between people who get paid comes under this banner, it’s hard to see
    what novelty is supplied here.

  • Well-Crafted Software. Volunteers please for making shitty
    software.

The Principled Programmer.

There must be some happy medium, some realm in which the statements we
make are wider in scope, and thus more complex, than rules, but not so
broad that they become meaningless platitudes that justify whatever
we’re doing but fail to guide us to what we should be doing.

I define this as the domain of the principle, and identify a principle
thus: a statement which can be violated, where the possibilities of
violation give us pause for thought and make us wonder about what it
is we value. To contrast this with the statements presented earlier:

  • violate a rule: meh, that’s OK, the other options are just as good.

  • violate a platitude: no, that’s impossible, or ludicrous.

  • violate a principle: ooh, that’s interesting.

Coming up with good principles is hard. The principles behind the
agile manifesto contain some legitimate principles:

  • Our highest priority is to satisfy the customer through early and
    continuous delivery of valuable software. Interesting. I can imagine
    that being one of many priorities of which others might be higher:
    growing the customer base, improving software quality, supporting what
    they’re using now and deferring delivery of new software until it’s
    needed. I’ll have to think about that.

  • Working software is the primary measure of
    progress. Interesting. This seems to suggest that paying off technical
    debt – exchanging one amount of working software for another amount of
    working software over a period of time – is not progress. I’ll have to
    think about that.

But then it also contains rules:

  • Deliver working software frequently, from a couple of weeks to a
    couple of months, with a preference to the shorter timescale. We ship
    a couple of times a day, and I don’t feel that’s worse.

  • Business people and
    developers must work together daily throughout the project. Is there
    anything wrong with every other day?

And platitudes:

  • Build projects around motivated individuals. Give them the
    environment and support they need, and trust them to get the job
    done. I cannot imagine a situation where I would hire people who do
    not want to do the work.

  • Continuous attention to technical excellence and good
    design enhances agility. This is tautological, as technical excellence
    and good design can be defined as those things that enable our goals
    and processes.

Why is it hard? I believe it’s because it’s highly personal, because
what you’re willing to think about and likely to get benefit from
thinking about depends on your own experiences and interests. Indeed
I’m not sure whether I want to define the principle as I have done
above, or whether it’s the questions you ask while thinking about
the validity of those things that are really your principles.

## Nice principles. Now go and turn them into
rules.

The thing about thinking is that I don’t want to do it when I don’t
need to. My currency is thought, so if I’m still thinking next year
about the things I was considering this year, I’m doing it wrong.

Principles are great for the things that need to challenge
the way we work now. But they should be short-lived. Remember the
beginner use of rules was only one of two important contexts? The
other context is in freeing up cognitive space for people who
previously had principles, and now want to move on to have new
principles. In short-circuiting the complex considerations you
previously had, mentally automating them to prepare yourself for
higher-level considerations.

Notice that this means that it’s a rule in isolation that doesn’t cause us any problems to violate. It may be that the rule was derived from a principle, so some thought went into its construction. Without that information, all we can see is that there are two possibilities and we’re being told that one of them is acceptable.

The challenge that remains is in communication, because it doesn’t
help for the context of a rule to be misidentified. If you’re a
beginner, and you describe your beginner rule and someone takes it as
an expert rule, they might end up talking about perspectives that
you’re not expecting. Also if you’re an expert and your expert rule is
perceived as a beginner rule, you might end up having to discuss
issues you’ve already considered and resolved.

So by all means, identify your principles. Then leave them behind and
discover new ones.

Posted in Responsibility, Talk | 1 Comment

Selectively caring

Posted on 2015-11-18 by Graham

When Choose Boring Technology was published earlier this year, it hit home for me. If you’re spending money trying to ship, say, a music notation app, there’s no point in rewriting the operating system scheduler.

Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps.

If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that’s existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you’re in trouble.

Today the personal lesson finally percolated out of this team decision. Why is it I can’t make any progress on software? I care about too many things. This isn’t just about choosing technology, which is a small part of what technologists do (though it does imply passing all of the other caring, about ethics and finding potential customers and selecting customers and retaining customers and making money and hiring people and firing people and evaluating performance and making the lunch and designing a product and creating an experience and plumbing the toilets and other things to other people).

It’s about those things, the technical things, and more. If I care about all of those things then there’ll always be something not quite right about what I’m doing, which will be morale-destroying. Or it will make me work on fixing the thing that isn’t quite right, rather than whatever I need to make progress on. Or both. Often both. And, of course, given the size of our industry and the number of bloviators in it, for any subject upon which it’s possible to have an opinion there will be multiple opinions written, so plenty of possibilities to research how to care about whatever it is I’ve decided to care about.

Choosing what to care about is a skill, and a valuable one to have. Choosing not to care about something doesn’t necessarily mean ignoring its impact, though that is one way to deal with it. You can hire someone else (directly or under contract) to care about it, make an arbitrary choice and go with that, or get someone else to make an arbitrary choice that you then follow.

If the division of labour was the driver of efficiency in the industrial age, then the division of caring is that driver in the information age. Now to choose what to care about.

Posted in Responsibility | Leave a comment

Week Seven

Posted on 2015-11-06 by Graham

Having spent a few weeks trying all of the things and letting life happen, this week was about selection and focus. What should I actually concentrate on, and put energy into?

It’s time to add some structure to this situation. Dropping all of the things and taking life as it comes was relaxing, enjoyable, and necessary. Re-moulding things and building something new out of the parts will be necessary to provide a new sense of engagement and purpose.

Posted in advancement of the self | Leave a comment

Week six

Posted on 2015-10-30 by Graham

This is a post about marmalade.

A “life hack”, if you will, that I learnt from Simon Stewart is to find things that I don’t do because I don’t like them, or think I don’t like them, and to do them. Do them again. Find out whether there’s anything to like about them, whether I missed something important, or whether my tastes have simply changed.

That is why breakfast this weekend featured the phrase “could you pass the marmalade, please, I don’t like it”.

This is not a post about marmalade.

Posted in Uncategorized | Leave a comment

Week five

Posted on 2015-10-23 by Graham

“You look so much happier!”

I get the best compliments. Also, I feel so much happier. I have put people, friendships, connections, and experiences first, and am taking advantage of the rewards.

One such experience was a visit a couple of further education (16-18 years old) computing classes in my county. I was mostly there to talk about my background in the industry and help them to understand what jobs there are and what employers look for. I was blown away by the things these students could make in their robotics classes though, with Mindstorms kits talking to laptops and mobile apps.

That was a huge step up from the turtle robots we had shuffling around the floor. in my school. And it still feels like there’s even more opportunity there, like there’s a huge gap between what a student sees computers being capable of and what they can do with the tools we (the industry) give them.

Posted in advancement of the self | Leave a comment