Future Challenges for Remote Working

When the COVID-19 lockdown forced many offices to close and their staff to work remotely, some of us saw what was unfolding as an… opportunity in disguise. Instead of the slow-but-steady decentralisation of work that’s very slowly become possible (technically, administratively, and politically) over the last 50 years, suddenly a torrent of people were discovering that remote working can work.

Man in sci-fi jumpsuit and futuristic AR goggles.
Unfulfilled promises of the world of tomorrow include flying cars, viable fusion power, accessible space travel, post-scarcity economies, and – until recently – widespread teleworking. Still waiting on my holodeck too.

The Future is Now

As much as I hate to be part of the “where’s my flying car?” brigade, I wrote ten years ago about my dissatisfaction that remote working wasn’t yet commonplace, let alone mainstream. I recalled a book I’d read as a child in the 1980s that promised a then-future 2020 of:

  1. near-universal automation of manual labour as machines become capable of an increasing diversity of human endeavours (we’re getting there, but slowly),
  2. a three- or four-day work week becoming typical as efficiency improvements are reinvested in the interests of humans rather than of corporations (we might have lost sight of that goal along the way, although there’s been some fresh interest in it lately), and
  3. widespread “teleworking”/”telecommuting”, as white-collar sectors grow and improvements in computing and telecommunications facilitate the “anywhere office”

Of those three dreams, the third soon seemed like it would become the most-immediate. Revolutionary advances in mobile telephony, miniaturisation of computers, and broadband networking ran way ahead of the developments in AI that might precipitate the first dream… or the sociological shift required for the second. But still… progress was slow.

At eight years old, I genuinely believed that most of my working life would be spent… wherever I happened to be. So far, most of my working life has been spent in an office, despite personally working quite hard for that not to be the case!

Driver's temperature being checked at the roadside by somebody in full protective equipment.
Apply directly to the head! Commuting looks different today than it did last year, but at least the roads are quieter.

I started at Automattic six months ago, an entirely distributed company. And so when friends and colleagues found themselves required to work remotely by the lockdown they came in droves to me for advice about how to do it! I was, of course, happy to help where I could: questions often covered running meetings and projects, maintaining morale, measuring output, and facilitating communication… and usually I think I gave good answers. Sometimes, though, the answer was “If you’re going to make that change, you’re going to need a cultural shift and some infrastructure investment first.” Y’know: “Don’t start from here.” If you received that advice from me: sorry!

(Incidentally, if you have a question I haven’t answered yet, try these clever people first for even better answers!)

More-recently, I was excited to see that many companies have adopted this “new normal” not as a temporary measure, but as a possible shape of things to come. Facebook, Twitter, Shopify, Square, and Spotify have all announced that they’re going to permit or encourage remote work as standard, even after the crisis is over.

Obviously tech companies are leading the way, here: not only are they most-likely to have the infrastructure and culture already in place to support this kind of shift. Also, they’re often competing for the same pool of talent and need to be seen as at-least as progressive as their direct rivals. Matt Mullenweg observes that:

What’s going to be newsworthy by the end of the year is not technology companies saying they’re embracing distributed work, but those that aren’t.

…some employers trapped in the past will force people to go to offices, but the illusion that the office was about work will be shattered forever, and companies that hold on to that legacy will be replaced by companies who embrace the antifragile nature of distributed organizations.

Distributed Work's Five Levels of Autonomy, by Matt Mullenweg.
I’ve shared this before, I know, but it exudes Matt’s enthusiasm for distributed work so well that I’m sharing it again. Plus, some of the challenges I describe below map nicely to the borders between some of

Tomorrow’s Challenges

We’re all acutely familiar with the challenges companies are faced with today as they adapt to a remote-first environment. I’m more interested in the challenges that they might face in the future, as they attempt to continue to use a distributed workforce as the pandemic recedes. It’s easy to make the mistake of assuming that what many people are doing today is a rehearsal for the future of work, but the future will look different.

Some people, of course, prefer to spend some or all of their work hours in an office environment. Of the companies that went remote-first during the lockdown and now plan to stay that way indefinitely, some will lose employees who preferred the “old way”. For this and other reasons, some companies will retain their offices and go remote-optional, allowing flexible teleworking, and this has it’s own pitfalls:

  • Some remote-optional offices have an inherent bias towards in-person staff. In some companies with a mixture of in-person and remote staff, remote workers don’t get included in ad-hoc discussions, or don’t become part of the in-person social circles. They get overlooked for projects or promotions, or treated as second-class citizens. It’s easy to do this completely by accident and create a two-tiered system, which can lead to a cascade effect that eventually collapses the “optional” aspect of remote-optional; nowhere was this more visible that in Yahoo!’s backslide against remote-optional working in 2013.
  • Some remote-optional offices retain an archaic view on presenteeism and “core hours”. Does the routine you keep really matter? Remote-first working demands that productivity is measured by output, not by attendance, but management-by-attendance is (sadly) easier to implement, and some high-profile organisations favour this lazy but less-effective approach. It’s easy, but ineffective, for a remote-optional company to simply extend hours-counting performance metrics to their remote staff. Instead, allowing your staff (insofar as is possible) to work the hours that suit them as individuals opens up your hiring pool to a huge number of groups whom you might not otherwise reach (like single parents, carers, digital nomads, and international applicants) and helps you to get the best out of every one of them, whether they’re an early bird, a night owl, or somebody who’s most-productive after their siesta!
  • Pastoral care doesn’t stop being important after the crisis is over. Many companies that went remote-first for the coronavirus crisis have done an excellent job of being supportive and caring towards their employees (who, of course, are also victims of the crisis: by now, is there anybody whose life hasn’t been impacted?). But when these companies later go remote-optional, it’ll be easy for them to regress to their old patterns. They’ll start monitoring the wellbeing only of those right in front of them. Remote working is already challenging, but it can be made much harder if your company culture makes it hard to take a sick day, seek support on a HR issue, or make small-talk with a colleague.
Teleworker dressed from the waist up.
On the Internet, nobody knows that you’re only properly-dressed from the waist up. No, wait: as of 2020, everybody knows that. Let’s just all collectively own it, ‘k.

These are challenges specifically for companies that go permanently remote-optional following a period of remote-first during the coronavirus crisis.

Towards a Post-Lockdown Remote-Optional Workplace

How you face those challenges will vary for every company and industry, but it seems to me that there are five lessons a company can learn as it adapts to remote-optional work in a post-lockdown world:

  1. Measure impact, not input. You can’t effectively manage a remote team by headcount or closely tracking hours; you need to track outputs (what is produced), not inputs (person-hours). If your outputs aren’t measurable, make them measurable, to paraphrase probably-not-Galileo. Find metrics you can work with and rely on, keep them transparent and open, and re-evaluate often. Use the same metrics for in-office and remote workers.
  2. Level the playing field. Learn to spot the biases you create. Do the in-person attendees do all the talking at your semi-remote meetings? Do your remote workers have to “call in” to access information only stored on-site (including in individual’s heads)? When they’re small, these biases have a huge impact on productivity and morale. If they get big, they collapse your remote-optional environment.
  3. Always think bigger. You’re already committing to a shakeup, dragging your company from the 2020 of the real world into the 2020 we once dreamed of. Can you go further? Can you let your staff pick their own hours? Or workdays? Can your staff work in other countries? Can you switch some of your synchronous communications channels (e.g. meetings) into asynchronous information streams (chat, blogs, etc.)? Which of your telecommunications tools serve you, and which do you serve?
  4. Remember the human. Your remote workers aren’t faceless (pantsless) interchangeable components in your corporate machine. Foster interpersonal relationships and don’t let technology sever the interpersonal links between your staff. Encourage and facilitate (optional, but awesome) opportunities for networking and connection. Don’t forget to get together in-person sometimes: we’re a pack animal, and we form tribes more-easily when we can see one another.
  5. Support people through the change. Remote working requires a particular skillset; provide tools to help your staff adapt to it. Make training and development options available to in-office staff too: encourage as flexible a working environment as your industry permits. Succeed, and your best staff will pay you back in productivity and loyalty. Fail, and your best staff will leave you for your competitors.

I’m less-optimistic than Matt that effective distributed working is the inexorable future of work. But out of the ashes of the coronavirus crisis will come its best chance yet, and I know that there’ll be companies who get left behind in the dust. What are you doing to make sure your company isn’t one of them?

How to not make a résumé in React

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

I’ve seen a fair share of tutorial links floating around in newsletters and Twitter and the like recently. They all promise the same thing, namely how to use React to create a résumé.

I mean, I get it. It’s important to have something to build towards when learning a new skill, especially with development.

At first blush a résumé seems like a good thing to build towards: They are relatively small in terms of complexity and can probably use content that already exists on your LinkedIn profile. If you’re looking for a job, it’s also a handy way to double-dip on a skill that is in high demand.

I checked out a few of these tutorials, and after noticing some patterns, I’d like to mention a few things you could do to your résumé instead. I’m not going to link to the ones I tested because I don’t want to give bad advice more exposure than it is already getting.

I can’t even begin to conceive of the kind of mind that, when faced with the question of how to put their résumé/CV online, start by installing a Javascript framework. My CV‘s online (and hey, it got me my current job so that’s awesome) and I think it’s perfectly fabulous. Simple, human-readable, semantic HTML with microformats support. Perfectly readable on anything from lynx upwards and you’d probably get by in telnet. Total size including all images, fonts, style and script is under 140kb, and can all be inlined with a quick command so I can have a single-file version that looks just as great (I use this version to email to people, but I’m thinking I ought to just inline everything, all the time). Under 1kb of my payload is JavaScript, and it’s all progressive enhancement: using an IntersectionObserver (which I’ve written about before) to highlight the current “section” of the document in the menu. Print CSS so it looks right when you put it onto dead trees. Etc. etc.

My entire CV requires a quarter of the bandwidth of just the JavaScript of any of the handful of React-based ones I looked up. The mind boggles. I tried disabling JavaScript on a few of them (even if you believe “nobody uses the Web without JavaScript” – and you’re wrong – then you have to admit that sometimes JavaScript fails) and they did horrific things like not loading images or links not working, as if <img> and <a> tags were something that requires you to npm install html@0.9 before they work..

A simpler, faster, more-accessible, more-secure Web is possible. It’s not even particularly hard. It just requires a little thought. Don’t take a sledgehammer to a walnut: the best developers are the ones who choose the right tool for the job. Your résumé/CV is not a real-time backendless application on a post-relational-backed microservices architecture, or whatever’s “hip” this week. It’s a page that you want to be as easy as possible to read by the widest number of people. Why make life harder for you, and for them?


New employees at Automatticlike me! – are encouraged to make a “howdymattic” video, introducing themselves to their co-workers. Some are short and simple, others more-ornate, but all are a great way to provide the kind of interpersonal connection that’s more-challenging in an entirely-distributed company with no fixed locations and staff spread throughout the globe.

In anticipation of starting, tomorrow, I made such a video. And I thought I’d share it with you, too.

Also available on: VideoPress, QTube, YouTube.

Without The Bod

Eight years, six months, and one week after I started at the Bodleian, we’ve gone our separate ways. It’s genuinely been the nicest place I’ve ever worked; the Communications team are a tightly-knit, supportive, caring bunch of diverse misfits and I love them all dearly, but the time had come for me to seek my next challenge.

(For anybody out-of-the-loop, I’m moving to Automattic after surviving their amazing, mind-expanding recruitment process).

Bodleian staff badge and keyring
My imminent departure began to feel real when I turned over my badge and gun card and keys.

Being awesome as they are, my team threw a going-away party for me, complete with food from Najar’s Place, about which I’d previously raved as having Oxford’s best falafels. I wasn’t even aware that Najar’s place did corporate catering… actually, it’s possible that they don’t and this was just a (very) special one-off.

Partry platters courtesy of Najar's Place along with drinks and cake.
Start from the left, work towards the right.

Following in the footsteps of recent team parties, they’d even gotten a suitably-printed cake with a picture of my face on it. Which meant that I could leave my former team with one final magic trick, the never-before-seen feat of eating my own head (albeit in icing form).

Dan on a cake
Of course, the first thing I was asked to do was to put a knife through my own neck.

As the alcohol started to work, I announced an activity I’d planned: over the weeks prior I’d worked to complete but not cash-in reward cards at many of my favourite Oxford eateries and cafes, and so I was now carrying a number of tokens for free burritos, coffees, ice creams, smoothies, pasta and more. Given that I now expect to spend much less of my time in the city centre I’d decided to give these away to people who were able to answer challenge questions presented – where else? – on our digital signage simulator.

"Play Your Shards Right" on the big screen.
Among the games was Play Your Shards Right, a game of “higher/lower” played across London’s skyscrapers.

I also received some wonderful going-away gifts, along with cards in which a few colleagues had replicated my long tradition of drawing cartoon animals in other people’s cards, by providing me with a few in return.

Coworkers competing agressively for tiny prizes.
“Wait… all of these Javascript frameworks look like they’re named after Pokémon!”

Later, across the road at the Kings’ Arms and with even more drinks inside of me, I broke out the lyrics I’d half-written to a rap song about my time at the Bodleian. Because, as I said at the time, there’s nothing more-Oxford than a privileged white boy rapping about how much he’d loved his job at a library (video also available on QTube [with lyrics] and on Videopress).

It’s been an incredible 8½ years that I’ll always look back on with fondness. Don’t be strangers, guys!

Dan says goodbye to Bodleian colleagues
My department’s made far too much use out of that “Sorry you’re leaving” banner, this year. Here’s hoping they get a stabler, simpler time next year.

Shredding eight years of old payslips

I’ve just cleared out my desk at the Bodleian in anticipation of my imminent departure and discovered that I’ve managed to successfully keep not only my P60s but also every payslip I’ve ever received in the 8½ years I’ve worked there. At a stretch, I might just end up requiring those for the current tax year but I can’t conceive of any reason I’ll ever need the preceding hundred or so of them, so the five year-old and I shredded them all.

If you’ve ever wanted to watch five solid minutes of cross-cut shredding shot from an awkwardly placed mobile phone camera, this is the video for you. Everybody else can move along.

Also available on QTube and on VideoPress.

Time-Efficient Shuffling

Some years ago, a friend of mine told me about an interview they’d had for a junior programming position. Their interviewer was one of that particular breed who was attached to programming-test questions: if you’re in the field of computer science, you already know that these questions exist. In any case: my friend was asked to write pseudocode to shuffle a deck of cards: a classic programming problem that pretty much any first-year computer science undergraduate is likely to have considered, if not done.

Interview with paper visible.
Let’s play at writing software. Rather than a computer, we’ll use paper. But to make it sound techy, we’ll call it “pseudocode”.

There are lots of wrong ways to programmatically shuffle a deck of cards, such as the classic “swap the card in each position with the card in a randomly-selected position”, which results in biased results. In fact, the more that you think in terms of how humans shuffle cards, the less-likely you are to come up with a good answer!

Chart showing the probability bias for an incorrectly-implemented Fisher-Yates shuffle, for a 6-card deck.
If we shuffled a deck of six cards with this ‘broken’ algorithm, for example, we’d be more-likely to find the card that was originally in second place at the top of the deck than in any other position. This kind of thing REALLY matters if, for example, you’re running an online casino.

The simplest valid solution is to take a deck of cards and move each card, choosing each at random, into a fresh deck (you can do this as a human, if you like, but it takes a while)… and that’s exactly what my friend suggested.

The interviewer was ready for this answer, though, and asked my friend if they could think of a “more-efficient” way to do the shuffle. And this is where my friend had a brain fart and couldn’t think of one. That’s not a big problem in the real world: so long as you can conceive that there exists a more-efficient shuffle, know what to search for, and can comprehend the explanation you get, then you can still be a perfectly awesome programmer. Demanding that people already know the answer to problems in an interview setting doesn’t actually tell you anything about their qualities as a programmer, only how well they can memorise answers to stock interview questions (this interviewer should have stopped this line of inquiry one question sooner).

Riffle shuffling
Writing a program to shuffle a deck takes longer than just shuffling it, but that’s hardly the point, is it?

The interviewer was probably looking for an explanation of the modern form of the Fisher-Yates shuffle algorithm, which does the same thing as my friend suggested but without needing to start a “separate” deck: here’s a video demonstrating it. When they asked for greater efficiency, the interviewer was probably looking for a more memory-efficient solution. But that’s not what they said, and it’s certainly not the only way to measure efficiency.

When people ask ineffective interview questions, it annoys me a little. When people ask ineffective interview questions and phrase them ambiguously to boot, that’s just makes me want to contrive a deliberately-awkward answer.

So: another way to answer the shuffling efficiency question would be to optimise for time-efficiency. If, like my friend, you get a question about improving the efficiency of a shuffling algorithm and they don’t specify what kind of efficiency (and you’re feeling sarcastic), you’re likely to borrow either of the following algorithms. You won’t find them any computer science textbook!

Complexity/time-efficiency optimised shuffling

  1. Precompute and store an array of all 52! permutations of a deck of cards. I think you can store a permutation in no more than 226 bits, so I calculate that 2.3 quattuordecillion yottabytes would be plenty sufficient to store such an array. That’s about 25 sexdecillion times more data than is believed to exist on the Web, so you’re going to need to upgrade your hard drive.
  2. To shuffle a deck, simply select a random number x such that 0 <= x < 52! and retrieve the deck stored at that location.

This converts the O(n) problem that is Fisher-Yates to an O(1) problem, an entire complexity class of improvement. Sure, you need storage space valued at a few hundred orders of magnitude greater than the world GDP, but if you didn’t specify cost-efficiency, then that’s not what you get.

Stack of shuffled cards
If you’ve got a thousand galaxies worth of free space you can just fill them with actual decks of cards – one for each permutation – and physically pick one at random. That sounds convenient, right?

You’re also going to need a really, really good PRNG to ensure that the 226-bit binary number you generate has sufficient entropy. You could always use a real physical deck of cards to seed it, Solitaire/Pontifex-style, and go full meta, but I worry that doing so might cause this particular simulation of the Universe to implode, sooo… do it at your own risk?

Perhaps we can do one better, if we’re willing to be a little sillier…

(Everett interpretation) Quantum optimised shuffling

Quantum ungulations
If you live in a universe in which quantum optimised shuffling isn’t possible, the technique below can be adapted to create a universe in which it is.

Assuming the many-worlds interpretation of quantum mechanics is applicable to reality, there’s a yet-more-efficient way to shuffle a deck of cards, inspired by the excellent (and hilarious) quantum bogosort algorithm:

  1. Create a superposition of all possible states of a deck of cards. This divides the universe into 52! universes; however, the division has no cost, as it happens constantly anyway.
  2. Collapse the waveform by observing your shuffled deck of cards.

The unneeded universes can be destroyed or retained as you see fit.

Let me know if you manage to implement either of these.

When Experienced Women Engineers Look for New Jobs, They Prioritize Trust and Growth

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

How can we increase gender representation in software engineering?

Our Developer Hiring Experience team analyzed this topic in a recent user-research study. The issue resonated with women engineers and a strong response enabled the team to gain deeper insight than is currently available from online research projects.

Seventy-one engineers who identified as women or non-binary responded to our request for feedback. Out of that pool, 24 answered a follow-up survey, and we carried out in-depth interviews with 14 people. This was a highly skilled group, with the majority having worked in software development for over 10 years.

While some findings aligned with our expectations, we still uncovered a few surprises.

Excellent research courtesy of my soon-to-be new employer about the driving factors affecting women who are experienced software engineers. Interesting (and exciting) to see that changes are already in effect, as I observed while writing about my experience of their recruitment process.

Shifting into Automattic

In October of this year – after eight years, six months, and five days with the Bodleian Libraries – I’ll be leaving for pastures new. Owing to a combination of my current work schedule, holidays, childcare commitments and conferences, I’ve got fewer than 29 days left in the office.

Dan's whiteboard: "You have [29] work days left to ask Dan that awkward question".
I’ve been keeping a countdown on my whiteboard to remind my colleagues to hurry up and ask me anything they need in order to survive in my absence.
Instead, I’ll be starting work with Automattic Inc.. You might not have heard of them, but you’ve definitely used some of their products, either directly or indirectly. Ever hear of WordPress.com, WooCommerce, Gravatar or Longreads? Yeah; that’s the guys.

Automatic gear stick.
It’s a gear stick. For an automatic car. ‘Cos I’m “shifting into Automattic”. D’you get it? Do you? Do you?

I’m filled with a mixture of joyous excitement and mild trepidation. It’s mostly the former, thankfully, but there’s still a little nervousness there too. Mostly it’s a kind of imposter syndrome, I guess: Automattic have for many, many years been on my “list of companies I’d love to work for, someday”, and the nature of their organisation means that they have their pick of many of the smartest and most-talented geeks in the world. How do I measure up?

Dan in the Rewley Library at the University of Oxford.
During my final months I’m taking the opportunity to explore bits of the libraries I’ve not been to before. Y’know, before they revoke my keycard.

It’s funny: early in my career, I never had any issue of imposter syndrome. I guess that when I was young and still thought I knew everything – fuelled by a little talent and a lot of good fortune in getting a head-start on my peers – I couldn’t yet conceive of how much further I had to go. It took until I was well-established in my industry before I could begin to know quite how much I didn’t know. I’d like to think that the second decade of my work as a developer has been dominated by unlearning all of the things that I did wrong, while flying by the seat of my pants, in the first decade.

Roof of the Clarenon Building, Broad Street, University of Oxford, showing the Muses.
I’ll be mostly remote-working for Automattic, so I can guarantee that my office won’t be as pretty as my one at the Bod was. Far fewer Muses on the roof, too.

I’m sure I’ll have lots more to share about my post-Bodleian life in due course, but for now I’ve got lots of projects to wrap up and a job description to rewrite (I’m recommending that I’m not replaced “like-for-like”, and in any case: my job description at the Bodleian does not lately describe even-remotely what I actually do), and a lot of documentation to bring up-to-date. Perhaps then this upcoming change will feel “real”.

An Unusual Workday

Some days, my day job doesn’t seem like a job that a real person would have at all. It seems like something out of a sitcom. Today, I have:

  • Worn a bear mask in the office (panda in my case; seen below alongside my head of department, in a grizzly mask).
    Bears in the office
  • Chatted about popular TV shows that happen to contain libraries, for inclusion in a future podcast series.
  • Experimented with Web-based augmented reality as a possible mechanism for digital exhibition content delivery. (Seen this thing from Google Arts & Culture? If you don’t have an AR-capable device to hand, here’s a video of what it’s like.)
    Virtual Reality at the Bodleian
  • Implemented a demonstrative XSS payload targetting a CMS (as a teaching tool, to demonstrate how a series of minor security vulnerabilities can cascade into one huge one).
  • Gotten my ‘flu jab.

Not every day is like this. But sometimes, just sometimes, one can be.

Adactio: Journal—Code (p)reviews

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

I’m not a big fan of job titles. I’ve always had trouble defining what I do as a noun—I much prefer verbs (“I make websites” sounds fine, but “website maker” sounds kind of weird).

Mind you, the real issue is not finding the right words to describe what I do, but rather figuring out just what the heck it is that I actually do in the first place…

Just shut up and let your devs concentrate, advises Stack Overflow CEO Joel Spolsky

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

If you want to attract and keep developers, don’t emphasize ping-pong tables, lounges, fire pits and chocolate fountains. Give them private offices or let them work from home, because uninterrupted time to concentrate is the most important and scarcest commodity…

A Research-driven Recruitment Story

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

[It] was initially frustrating to not be able to tell you things about who I am and what I’ve done. But it’s great that it’s a level playing field. By the final interview I was liking the process so much that I was reluctant to share my CV and de-anonymize myself. – Successful Careers applicant…

recruit.ox.ac.uk Permalink Generator

If you’ve ever applied for a job with my employer, the University of Oxford, you’ll have come across recruit.ox.ac.uk, one of the most-frustrating websites in the world. Of its many problems, the biggest (in my mind) is that it makes it really hard to share or save the web address of a particular job listing. That’s because instead of using individual web addresses to correspond to individual jobs, like any sanely-designed system would, it uses Javascript hackery and black magic to undermine the way your web browser was designed to work (which is why, you’ll find, you can’t “open in new tab” properly either), and instead provides its own, inferior, interface.

Some day I might get around to writing e.g. a userscript and/or browser plugin that “fixes” the site – from a user’s perspective, at least. But for the time being, because this morning I needed to share via social media a link to a UX developer post we’ve just advertised, I’ve come up with a little bookmarklet to fix this single problem:

recruit.ox.ac.uk Permalink Generator

Drag the bookmarklet to your bookmarks toolbar, then - when on the recruit.ox.ac.uk site - click it to use it.

This tool makes it easy to get permalinks (web addresses you can save or share) for job listings on recruit.ox.ac.uk. It might be adaptable to make it work with other CoreHR-powered systems, if it turns out that this missing feature comes from the underlying software that powers the site: it could also form the basis of a future userscript that would automatically fix the site “on the fly”. Here’s how to use it:

  1. Drag the link below into your browser’s bookmarks (e.g. the bookmarks toolbar).

    recruit.ox.ac.uk permalink

  2. When you’re on a recruit.ox.ac.uk job page, click on the bookmark. A permalink will appear at the top of the page, for your convenience. If you’re using a modern browser, the permalink will also appear in the address bar.
  3. Copy the permalink and use it wherever you need it, e.g. to share the link to a job listing.

If you have any difficulty with it or want help adapting it for use with other CoreHR systems, give me a shout.

We Hire the Best, Just Like Everyone Else

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

One of the most common pieces of advice you’ll get as a startup is this: Only hire the best. The quality of the people that work at your company will be one of the biggest factors in your success – or failure. I’ve heard this advice over and over and over at startup events, to…

One of my favourite hosting companies is recruiting using anonymous online interviews, in an effort to combat industry sexism

This link was originally posted to /r/girlsgonewired. See more things from Dan's Reddit account.

So, in May 2015, we made the huge decision to start an anonymous recruitment process. The biggest change compared to tradition recuiting is this – your first two interviews are truly anonymous. We conduct them over instant messaging and run our skills tests remotely too.

You won’t even have to give your real name or a CV in the initial stages. We don’t know anything about you that you don’t choose to present in the interview.

That makes us work hard for explicit goals. We want to know about your:

Most valuable skills
Ability to learn
Ability to work effectively in a team

We make decisions based on those factors. Avoiding the “X factor” of cultural fit, which we’ve seen as an excuse for all kinds of implicit and explicit bias across industries.

We also want to be respectful of your time, your enthusiasm and your interests – we’ll test not just what you know but what you can learn. Our focus is on letting you put your abilities to the fore, without fear that you’ll be judged on irrelevant things. We define the job, we define the skills, and we want to test those without bias.

Our culture comes from you, the best person for the job at the end of the process. Of course we still need to meet you, we want to meet you. But we will start our interviews on the solid foundation of anonymity. Only at the final stages will you be asked to come in for a face-to-face interview.