Choosing the next job rather than finding it…

A few weeks back, at the end of April, my contract with the Suura project in TCD ran out. We were close enough to the finish line that I offered to stay on for a few weeks unpaid, but TCD rules prohibited this, so that drew a line under the Suura project for me, though I did walk away with a patent being filed in my name (and four others) for the system and a promise of equity share should things ever sort themselves out.

But with the wedding round the corner and having gone from looking at very high potential rewards to yet another run through the recruitment process, I was feeling a bit miffed at the startup life. I went through my usual post-contract routine of writing up my last log entry on the job (always keep a log of what you do and plan during the job), and then taking a week and doing absolutely nothing. Not lazing about, but studiously doing nothing, letting the mind go null and letting the “dammit, I missed the morning meeting with X” sensation die away (because if you don’t, you can’t focus on the next thing, you wind up scattered all over the place mentally).

After that, I sat down and went through my logs from the last four or five years and as many SMEs and startups, and noted all the things that bugged me about those roles; and all the things that I liked in them and wanted to see more often. And I went through my current google reader subscriptions and the items I found myself reading in dZone and Hacker News and Programming Alltops. I added all those together and also looked at how the upcoming wedding was going to change priorities, and sat down to draft a list of criteria for the next role.

I know that sounds a bit arrogant, especially in our current economic climate, and worse than that, it sounds like the advice every career coach, life coach and self-help book writer out there peddles on a daily basis. And I’m a bit more reactionary on this sort of thing than most in our industry – I thought Mike Rowe’s take on work and jobs was a breath of fresh air in a room filled with manure (the second ten minutes, not the first ten – the first ten are just fun 😀 ):

But here’s the thing – desperately going from job to job really is a bad idea in our industry. It can look appalling on the CV and thanks to Jason Calacanis’ tweet-started shouting match a few months back, it’s the hot-button topic of the month in some sectors. And even skipping the points that there are often valid reasons for jumping from role to role on a near-annual basis, there’s the fact that it’s just not very good for your personal life either (and dammit, I like having a personal life). So I wanted the next role to be long-term, and rather than just go for the first random job that I could do that paid enough, I thought I’d try a more focussed search for “the” role instead, to see how it’d play out.

So here were the criteria I came up with.

The role should be for a large, stable company. Well, obviously. But it was more than just because startups are so volatile, it was because in all the SMEs and startups I’ve been in so far, there’s an inversely proportional relationship between the size of the company and the panic level in the company when absolutely anything goes wrong. Regardless of the true significance of the problem, pretty much all the SMEs I’ve been in have been guilty of assigning tasks according to the volume of the shouting from the clients at one point or another; or of getting into some serious bikeshed design discussions. The theory was, a large and stable company won’t have quite such a rapid panic response – it simply couldn’t if it had enough people in it. Panic responses generally need a startup-style environment with one or two people in charge, without that, panic can’t really take hold.

It should be either a systems administration or a low-level programming role. The roles I’ve held and the work I’ve done in the past five to ten years have all been caught between sysadmin and low-level programming, from linux device drivers to tuning databases for LAMP stacks. That’s the kind of level I’m most comfortable with, and I’m still not even close to bored with it or to thinking I know even half of what there is to know about it. But I’ve never made the decision between sysadmin and dev; and devops isn’t really a half-way house, so I have both down as acceptable.

It should have a focus of either “scale” or “mobile”. Because at the moment, aside from a few niches like security, there’s nothing else going on that’s interesting. Building large-scale systems and building mobile systems; it’s either of those or nothing if you want to do interesting stuff, because as of yet, we don’t know how to do either. And that means opportunity – to learn, to play and to profit.

It should be a role using C or Python or both. I’m fairly okay with C. After fifteen years of using it, I’ve gotten to the point where it’s not so much quirky as normal. And I’m really enjoying learning to use Python, and I’m impressed with what it can do at the application level. So using C would make my work life easier, and Python would be fun. Both would be perfect. Granted, this isn’t a deal-breaker, but it is important. And definitely no Java. That abomination unto dog is something I find painful to use at the best of times.

It should be in Dublin city centre. For eleven years, I spent between 90 minutes and two hours a day travelling by bus and train to get to college or work. For a further two years, I spent a similar amount of time driving that route. Then I moved to the city center and could walk to work in under twenty minutes. I’m never, ever, going to accept a work commute over 30 minutes again. Life’s just too short, and time’s too valuable.

It should be a job for the next 5-8 years, not the next year or two. After a few years of having companies fall out from under me, or become places that were toxic to stay in, I’m sick of instability. I’m craving a role where knowing where I’ll be in a year is not an act of divination. I want to work in a place where market pressure doesn’t turn everyone into foaming-at-the-mouth release junkies, or the-world-is-ending paniced firefighters, but where a sensible timetable survives at least the first brush with reality (even if it doesn’t survive intact and whole).

The salary should be in an acceptable range. I’m not greedy by nature, unless we’re talking about cake. As far as money goes, I’m normally of the opinion that I want to pay my bills, have health insurance and a pension, buy an occasional toy, and have some savings for a rainy day. That doesn’t actually take as much as you’d imagine. However, in our industry, salary is also a communications channel, and in the business world, it’s a statement of how your work environment will treat you. So I want mine back up where it would have been had I not taken a kicking from the Revenue Commissioners for working in a college startup (smart economy, eh? How about not levying contract researchers for pensions they can’t benefit from while they try to start SMEs you can tax?). Besides, I was about to get married, and a family isn’t far behind that, and while I’m not greedy by nature, I also like the idea of my kids getting to go to college and having a decent life.

On top of those criteria, there were other things in the back of my mind about the kind of people and the kind of management styles I prefer, but those weren’t well-formed enough to make the list. So with those criteria, I sat down to draw up a list of suitable companies, and I came up with a grand total of three – Google, IBM and Amazon. A fourth was added after talking to a few others in the industry (Facebook), and Amazon was moved a bit down the list for dev roles after talking to a few other friends. As it happened, Google had been asking me to interview for a few months, so they were up first, but CVs and emails went off to contacts in the others. Google’s interviews were a washout, however, as I’ve mentioned before.

The first to respond of the three remaining candidates was IBM. They’d been on my “would like to work there” list since they opened the Linux Technology Center the year I graduated, I had friends working there happily for years, and they certainly fitted the bill for being large and stable. When the initial phone contact I got turned out to be someone I’d known back in my PhD days and I learnt that the role was focussed on the low-level work needed for dealing with large-scale systems, it got very promising indeed. The initial interview was tough enough to be interesting, but what really got me hooked was the mindset of the managers doing the interview. Commitment to a healthy work-life balance, a strong emphasis on professionalism rather than rock-star programming, and sane expectations of workloads. And a fairly comprehensive lack of bullshit didn’t hurt.

It was at the point where I was walking away from the second interview, looking at green fields and rabbits and trees and a horizon all around (live in the Docklands for a year; you’ll crave those things too) that I realised not only was this a good fit to my criteria (with a small tweak to the “Dublin city centre” criteria), but that I really wanted to work here. Happily, they offered, I accepted, and I started work in the new role this week and am currently hip-deep in ﻿anagnorisis! So maybe choosing the job you want is a good idea, at least for software engineers…

3 thoughts on “Choosing the next job rather than finding it…”

Firstly, I’m glad you have found a job that fits what you are looking for and setting criteria in advance sounds very wise.

I don’t think that working on a shorter-term, temporary basis is quite so terrible as you imagine. I agree there is less security but there can also be a lot of freedom. And surely the main things that are good for one’s personal life are a proper balance and happiness with one’s job?

I won’t be able to erase the image Mike Rowe has created for me for quite some time 🙂

I think proper balance is definitely important Susan, but I’ve found that the startups and SMEs I’ve worked with have far too little inertia to really get a lot of work done during office hours – pretty much all the cool stuff they do is stuff developers do at home and bring in, and that’s just, well, stupid, from a business model perspective. Larger companies may, it’s true, have too much inertia – but it’s easier to create a skunkworks and reduce inertia than it is to convince a manager that it’s a bad idea to flit about from job to job depending on the volume of the phone call from the client!