On immutable data structures…?

If you write a scholarly publication and cite another one, what you say about it depends on its mutability. An article or a book can be cited by saying “this publication I’m identifying here says this”. Maybe you have to version your claim: “the second edition of this publication says this”. They’re immutable. Even if the third edition doesn’t say the thing you relied on in constructing your argument, the second edition still did. Someone who can get access to that second edition can look at it and see how you built your synthesis.

You can’t do that with a website. Websites change. Instead, you have to say that “this website identified by this URL, on the date that I read it, said this”. Someone who comes along later has to sort-of trust that, because if the website no longer says that, it might not be possible to tell whether it ever did say that, or whether you’re telling porky pies about your research.

Dependencies in software systems are usually given as if they work like book citations:

gem 'rack', '1.0'

…looks like it says “the thesis that’s constructed by my software is a synthesis in which version 1.0 of rack is axiomatic”, but it doesn’t. It’s really saying “at the time that I want you to think that I actually tested this stuff, it was true that the thing identified by being version 1.0 of rack was…”. It’s really a poorly-constructed website citation.

It’s fun to think, particularly in light of the npm shenanigans, just how long that dependency you didn’t bother downloading will still be around. You can presumably forget about relying on commercial software, as the licence agreement is the legal equivalent of Vader saying “I have altered the deal. Pray I do not alter it any further.” And indeed you can forget most open sores licences, which don’t put any requirements on your supplier. But what about the GPL? Version 3 (retrieved from this URL on 24th March 2016) says that anybody who distributes licensed software as object code may, as one possible way to provide access to the corresponding source code, provide that object:

accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge

What if the person you got the object code from dies within that three year period, do you have the right to ask the executor of their estate for the source code?

In which I interview so you don’t have to

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.

Turn it off and back on again

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.