US tech resistance cheatsheet for Australians

I gave an Australian friend a rundown on my sources of information about US opposition to the incoming Trump administration, focussed on tech workers, and she pointed out that my resources were worth sharing; the “Australian technology worker following US tech industry organising” position is not very common. Here’s my little collection of links:

Tech Solidarity. Tech Solidarity is a series of meetings being run in major US cities for technology industry workers on the subject of solidarity with other workers and with technology users, against an authoritarian Trump regime. There’s a Tech Solidarity website, but the best place to find out about their meetings is their Twitter account, and the best place to find out about their politics is the @Pinboard Twitter account run by Tech Solidarity co-organiser Maciej Cegłowski.

Neveragain.tech. This is a specific pledge by technology industry workers to not be involved in building technology for the US government to target individuals based on race, religion, or national origin, as well as advocating for specific policies in our workplaces and protesting unethical practices. I am a signatory and several of my friends are organisers. A Tech Solidarity meeting was key in launching the pledge.

Indivisible Guide. A guide to influencing members of Congress when your goals are largely defensive and obstructionist, ie, to hinder the dominant party in Congress or the President’s party in implementing their policy platform.

While this guide is interesting, I think considerable caution is called for in applying much of it to Australian politics without asking Australian activists and staffers for their advice. For example, party discipline in Australia is extremely strong — your representatives, if members of a major party, almost invariably vote with that party — and Cabinet and the ministry are appointed from amidst the members rather than separately. The executive being drawn from the legislature is very very different to how the US executive branch works. The chapter on four local advocacy tactics that actually work may have some inspiration for beginning to engage with your state or federal MP’s local activities if you haven’t done so before.

There are several guides to opposing specific Trump administration policies and initiatives, such as Resistance Manual and the re:act newsletter. There must be more of these appearing every day; I’m not following them closely since the calls to action usually require being a constituent of US members of congress and/or being a US resident.

Learning more about a remote working position

I’m in the process of wrapping up a long period of working remotely at least part-time from home, beginning in 2006 when I enrolled in a PhD program and continuing through my time at the Ada Initiative and at Stripe to this year.

My take on working remotely in future is really “it depends on the details” (and likely different details for different organizations). To that end, I contributed some suggested questions you could ask to Hypothesis’s Working remotely guide, which they’ve incorporated in a slightly edited form. Here’s my original questions; I’ve also added a few more at my end after some feedback from Andrew (himself a veteran of around seven years of remote work).

Introduction

Before you start working remotely at a new organization, you should explore how they structure remote working and if there are any expectations mismatches between you and the organization. A particular remote job may or may not be a match for a particular remote worker.

Important: I don’t think there is any one right answer to any of these questions. It’s a question of fit between your working style, the position itself, and the relationship of the position to the rest of the organization. But the answers are worth knowing so that you can evaluate your fit and make plans for effective remote working.

Sources of information

This entry has a lot of questions, too many for a “do you have any questions?” section of an interview. But you can use other sources of information to get most answers, especially about organization-wide questions:

  • the job description, and descriptions of similar roles
  • the organization’s website, particularly the About and Careers pages
  • the section of the employee handbook dealing with remote work
  • the LinkedIn pages or websites of your future manager and colleagues
  • longer, separate, conversations with your recruiter or hiring manager
  • your offer conversation or letter, or your contract

Some questions you also may only need to ask if you hear of concrete plans to make a change to the organization (eg, you learn that a new office is about to open near you).

Questions

How are you remote and who are you remote from? This post is using ‘remote’ to mean something like “most days, you are not in face to face contact with any colleagues.” But you should be aware of the details: will you be working without in person contact with teammates or with the wider organization almost all of the time? Do you have any colleagues in your team or your wider organization in your city or region, or who regularly visit? Will you work on any joint projects with them? Will you be able or be expected to sometimes work with them in person even if there’s not a permanent office space?

Separately, is in-person contact with vendors or customers part of the job?

Is your immediate team remote? Is your manager remote? Being a remote member of a team that is all working remotely from each other is different from a team which is mostly located in an office with each other. Likewise, being managed by someone who is in an office has some potential advantages (for example, access to information circulating through verbal grapevines, being able to access answers from colleagues for you quickly), as does being managed by someone who is themselves remote (a direct appreciation for experiences specific to remote workers, a personal interest in advocating for them).

How many remote workers are there at the rest of the organization? What percentage of teams you will work closely with are working remotely, and what percentage of employees overall are working remotely? Working as one of very few remote workers for an organization where most employees are in an office together is different from a mostly or entirely remote-working organization.

What’s the future of remote work at the organization? If the organization is mostly or entirely remote, are there any plans to change that? If the organization is mostly office-based, are there any plans to change that? If an office is likely to be founded in your city or region soon, will you be able or be expected to work from it?

You may be considering a job on the understanding that the remote work will be of very short duration (eg, an office is opening in your city in two months time). Is there any chance the time will be longer, and are you OK with that?

What is your manager’s approach to remote workers? How frequently will they speak with you and through what media? Will they expect you to travel to them? Will they sometimes travel to you? Have they managed remote workers before?

How long have there been remote workers for? Is the organization new to having remote workers or has it had remote workers for a long time and bedded down a remote working style?

What is the remote working culture like? Is most collaboration over email, text chat, phone, video conf, or some other means? Are there watercooler-equivalents like social IRC channels or video chats? How active are they? Are remote workers mainly working from home or from co-working spaces? Are there occasional team gatherings for remote workers to meet colleagues in person and are they optional or compulsory?

How flexible are the hours? Not all remote work has flexible hours; you may have mandated work hours, or core hours, or shifts, as in any other role.

Are the remote workers spread across multiple timezones? If so, are your team and closest collagues in your timezone or another one? Are you expected to adapt your working hours to overlap better with your colleagues? How are meetings and other commitments scheduled across timezones? Do they rotate through timezones or are they always held in a certain timezone? Are you ever expected to attend meetings well outside your working hours, and if so, how often is this expected and do your colleagues in other timezones face the same expectations?

What are the benefits for remote workers? Will the organization reimburse any of your remote working expenses, such as membership of a co-working space, home office furniture, or your home Internet connection costs? If you’re working in a different country from most of your colleagues, will you get equivalent benefits to your colleagues (eg, health insurance coverage)?

What are the travel expectations for remote workers? Are you expected to travel to headquarters or other offices or customers, and if so, how often and for how long? What are the travel policies and allowances for remote workers? How do these travel expectations compare to those of non-remote colleagues?

Sometimes you will be remote from an organization with an office or even headquarters in the same city as you. Will you be able or expected to visit the office? How often? Will there be resources for you (eg, hot desks, meal provisioning)?

What are the career progression possibilities for remote workers? As a remote worker in a partly non-remote organization, could you move into more senior positions over time, such as team leader, middle manager, or executive? Could you move into other teams in the organization, and if so, which ones? Are there some roles that are closed to remote workers? Match these answers to your own career goals.

What’s the training process like? Must you or can you spend a period of time in an office or visiting a colleague for training? Must you or can you do your training remotely using documentation, videos and similar? Will a trainer or colleague have some time assigned to remotely train you?

Is there support for first-time remote workers? If you haven’t worked remotely before, will the organization support you in learning how to work remotely, and if so, how?

See also

A very partial list of resources, focussing on individual remote workers and their experiences and strategies:

Creative Commons License
Learning more about a remote working position by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Tech interviews, too much homework, and the motherhood question

There’s a fascinating discussion around technical interviews recently; would both candidate experience and hiring signal be improved by revising the current round of (basically Google-inspired) non-runnable algorithm-centric coding examples completed under time pressure?

I’ve been following Thomas Ptacek’s tweets about it for a few months, for example:

Then last week Julia Grace wrote A Walkthrough Guide to Finding an Engineering Job at Slack:

We’ve put a great deal of effort into designing our interview process so that it is comprehensive and consistent, and are working hard to remove as many points of bias as possible. To date we’ve found it successfully identifies people who will succeed here — those with a high degree of technical competence who also embody Slack’s values: empathy, courtesy, craftsmanship, solidarity, playfulness, and thriving[…]

We’d like to get an idea of how you write code in the real world, since we feel this is the best indicator of how you’d write code day to day here at Slack. Granted, the Slack codebase is larger and more complicated than any technical exercise, but we have found the technical exercise to be a good indicator of future performance on the job. There are great engineers at big name companies and at small ones, so this gives everyone a chance to shine independent of where they are now.

This varies by position, but generally you’ll have a week to complete a technical exercise and submit the code and working solution back to us.

Uncritical praise of take home exams started to ring alarm bells for me. I recall take home exams from university; one of my majors was philosophy, which tended to assign a long essay (eg, 4000 words) to be completed over 6 weeks or so, and a take-home exam (eg, 2 essays of 1000–2000 words) to be completed with a four day deadline. I moved out of a rural town to go to university and lived on my own. From age 19, I also financially supported myself. I loathed take home exams, because I was competing with people who would get the exam, go home, and work on it all week in the house they lived in with their parents. No job. No housework. (Admittedly, no self-imposed decision to take 125% of a normal course load every year for four years of university either, that one was on me.)

And that was before I had two children. I’m not at all excited about tech interviews moving to a model where I’m doing a huge amount of work in my own time, because I do not have a huge amount of free time. Anecdotally, I have already heard of people spending in excess of 20 hours on Slack’s coding exercise. Freeing 20 hours in a week is a non-starter for me, especially if I’m not a clear finalist for the job. Slack is administering these take home assignments prior to on-site interviews, and is a very sought after workplace; it’s quite possible their process will be widely copied and people will regularly be doing a couple of days of coding before in-person interviews, for many many jobs.

To be fair, I have also read through Steve Yegge’s Get that job at Google and estimate that, at my current levels of free time, it would probably take me a couple of years to complete the preparation he recommends. (I have an undergraduate degree in computer science and mathematics — the philosophy major was a separate degree — and a PhD in computing, but at this distance I am far from passing an exam in discrete maths.) But I also wouldn’t be required to submit work samples proving I’d spent that time.

I am also aware that other positions require extensive preparatory work for job interviews for senior candidates, such as preparing sample budgets or strategy presentations or similar, but it’s at least more common only to give such large amounts of work to later-stage candidates for the position.

Let’s not get uncritically excited about adding (yet another!) screen for “isn’t a mother of young children”. I am thrilled that Camille Fournier has made several similar points in Thoughts on Take Home Interviews (also available on her blog):

On twitter, a discussion ensued about whether asking people to spend time at home doing exercises didn’t itself cause bias, against those who did not have a lot of spare time to be doing take-home exercises. Julia mentioned that they expect it to take 2–4 hours, but admitted that some people got really into the project and spent far longer than that[…]

The creative take-home also seems likely to select for those with free time, because if it is really an exercise that some people want to overdo, they will overdo it and you will have a hard time not rewarding that enthusiasm (why shouldn’t you!). And while it’s ok to ask for a few hours, building something that rewards those who can spend far longer is likely to bias against those who have, say, kids to take care of after work and on weekends, or other activities that limit their free time.

Gaëtan Voyer-Perraul also notes in a reply:

If this thing catches on, then it’s going to become a gating mechanism for every developer job in existence. New grads will be faced with hundreds of hours of “take-home” work that goes into the same black hole as their resumés.

Also worth a read: Rod Begbie gives a postmortem of a take-home interview question he used to administer.

I’m excited about revising the technical interviewing process, which will require both experimentation and evidence. While experimenting, and as the tech industry actively seeks candidates from under-represented backgrounds, the ability of candidates to interview with your organisation without tens of hours of free time for take-homes in addition to time for on-site interviews should be a core design principle for your interview process.

Remembering Telsa Gwynne

Telsa Gwynne, whom I knew through my time in the LinuxChix community between 2000 and around 2007, died this week:

Telsa is the direct inspiration for the entire 15 years of content on this website, especially the personal diary. Before joining LinuxChix, I first knew Telsa through her online diary (its archival title, “This was a diary, once”, is painful to read now), which I heard about through someone who read Alan Cox’s diary, and I was struck by how striking daily life could be in written form. Telsa’s diary was full of personality and snark, and singlehandedly inspired me to begin writing about my life online too.

I thought of her as a net celebrity, although not in the usual way of “married to Alan Cox”, but as “writer of one of my favourite websites”. I was therefore a little bit shy about directly interacting with her when I initially joined the LinuxChix lists in 2000, but I first met her in person in 2001 at linux.conf.au when she and Malcolm Tredinnick were hanging around debriefing and complaining about CVS, on which he was teaching a tutorial that year which Telsa later wrote up. She was grumpy and kind and normal, even if she did know CVS.

Andrew saw her again at LCA in 2003, but I didn’t go and I think I only met her one more time, in Wales in 2004 when we visited their house and due to poor planning with trains, ended up staying the night. Telsa and Alan were kind hosts and we enjoyed Telsa’s huge knowledge of local history as we walked all around Swansea.

Telsa’s final diary entry in 2006 says she “plain[ly] and simpl[y] los[t] interest in running to stand still just to understand how to use anything mechanical.” However hard she worked for it, I remember her as profoundly technically knowledgeable and an excellent teacher. A great deal of my initial learning about both CSS and character encodings came from her, and she was well known as a high level user of DocBook. A friend shared one of her posts to a private LinuxChix technical list today, walking through the differences between library packages and -devel packages in Linux distributions, and their implications for compiling software.

I hadn’t been in contact with Telsa since she or I variously withdrew from our common online communities, so since 2007 or before. I kept an eye on the very occasional updates to her website, and was pleased to think that she had found a more satisfying life outside her Free Software community volunteering. I still find this a happy thought.

Telsa was also a critical inspiration to me as an activist: in the early 2000s (and still) it was hugely controversial to either believe that open source communities could still work if they were more civil (the entire LinuxChix project was partly an experiment with that), and even more so to insist that they should be. Telsa is the earliest person I can think of who stood up in an open source development community and asked it to change its norms in the direction of civility. I don’t know how heavily her online harassment experiences played a part in her departing Free Software and some online communities — I hope it wasn’t a large part — but I’m sorry it happened and I’m angry.

Telsa was a brilliant and kind and strong person, and I am sorrier than I can say that we will never be in contact again. To Alan, Debbie and others who loved her: my profound sympathies for the loss of an amazing person.

Other memorials:

Telsa online:

Creative Commons License
Remembering Telsa Gwynne by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Quick hit: Google publishes their EEO-1 diversity data

This article originally appeared on Geek Feminism.

As promised earlier this month, Google’s diversity data is now up on their blog.

They write:

We’ve always been reluctant to publish numbers about the diversity of our workforce at Google. We now realize we were wrong, and that it’s time to be candid about the issues. Put simply, Google is not where we want to be when it comes to diversity, and it’s hard to address these kinds of challenges if you’re not prepared to discuss them openly, and with the facts.

Their numbers — globally — are 70% male, 30% female (this seems to add up to 100%, which suggests that either Google or the EEO-1 process need to review their gender categories), dropping to 17% female among their technical employees. We’ve tabulated some data at the Geek Feminism wiki. You can compare with female-male breakdowns from some other companies (many quite small) at We Can Do Better.

Google’s US workforce is also 2% Black, way below US national figures of 13% nationwide and 3% Hispanic against 17% nationwide. (Nationwide figures from US Census numbers dated from 2012 and rounded to the nearest whole number to have the same precision as the Google figures.)

What do you think? Is disclosure a meaningful action here? Are you surprised by Google’s figures? Do you think the rest of the tech industry will or should follow?

Remembering Malcolm Tredinnick

I flew home from the US yesterday and when I arrived in Sydney I got a message from my husband saying that Malcolm Tredinnick had died. According to this piece by Simon Dulhunty, he was found on Monday to died at home in Sydney, possibly after a seizure, while I was at PyCon 2013.

Malcolm Tredinnick speaking to an audience
Malcolm Tredinnick speaking at DjangoCon 2008 (by Sebastian Hilling CC BY-NC)

I’ve known Malcolm slightly since my first linux.conf.au in Sydney 2001. In late 2004 I interviewed for a job at CommSecure (since closed) where he was then working, having been a lead developer of and continuing to maintain and develop a real-time data delivery system for the Hong Kong stock exchange. (The eventual end of that contract was the reason CommSecure later closed.) He was also my boss for about half of 2005 until I left to begin my PhD in early 2006.

I still caught up with him at technical events, the last long conversation I remember with him was at PyCon AU 2011 where my husband Andrew and I had a very Malcolm conversation with Malcolm, which roved over the paperwork hassles of having no fixed address (Malcolm travelled a lot and went through periods where he housesat or lived in serviced apartments for a while), the Australasian chess community, and some gentle mutual trolling between him and Andrew over narrative testing.

What I will remember most about Malcolm is that he was a teacher at heart. I never personally had this relationship with him, but I knew several people at CommSecure and elsewhere who Malcolm had tutored or mentored in programming, often over a very long period of time. Elsewhere I know he had taught mathematics (long before I knew him, he very nearly completed a PhD in mathematics when his area suddenly became fashionable and about 50 years of work was done in 6 months by incoming mathematicians) and chess. I will also remember his dry and sadonic approach to nearly everything (for a very recent example, Malcolm gives useful parenting advice), combined with “really, how hard could it be?” used both straightforwardly and distinctly otherwise. Goodbye Malcolm.

Update, funeral plans: Ray Loyzaga who was Malcolm’s close friend, and long-time founder-CEO of CommSecure, has announced that Malcolm’s funeral will be at 2:30pm Thursday April 4, at Camellia Chapel, Macquarie Park Cemetary, North Ryde, Sydney.

Other memorials:

Malcolm online:

Creative Commons License
Remembering Malcolm Tredinnick by Mary Gardiner is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Fun at LCA 2013: my picks for Thursday and Friday

Thursday

I rarely go to LCA’s tutorials, but really, after years of not having to worry too much about distributed version control systems due to having in-house technical support from my husband, a (now former) Bazaar developer, it’s probably time that I came to grips with git. Hence Git For Ages 4 And Up (Michael Schwern) is tempting, hopefully it’s OK for those of us who do use terms like “directed acyclic graph”. This does mean missing Wiggle while you work (Neil Brown) though: apparently you can’t be a git beginner whilst being interested in newfangled patching algorithms.

After lunch The IPocalypse – 20 months later (Geoff Huston) calls to me: it’s the sequel to his LCA 2011 keynote, which is the one that stood out to me. (Well, and Mark Pesce’s, yes, but funnily enough his actual content largely passed me by.) All that doom and gloom, and now what? Has IPv6 cost us our Internet?

A Tridge talk (Building a free software telemetry radio system) is an even more obvious pick than a Matthew Wilcox talk. (Although why did we put that particular talk up against Buffer Bloat? Tridge is going to talk about TCP performance issues.)

In the afternoon Keith Packard has a new passion (Teaching Robotics and Embedded Computing with Legos and Arduino) and then Ristretto: run-time types for JavaScript (Shane Stephens) sounds alarming. In a good way.

Friday

It might also be a two-tute LCA, with Beyond Alt Text: What Every Project Should Know About Accessibility (Denise Paolucci) up first. BUT NovaProva, or How I Did Six Impossible Things Before LCA (Gregory Banks) is the good crack (“NovaProva implements true reflection in C/C++”???), so… difficult!

After lunch, Asheesh Laroia’s Quantitative community management is closer to what I do but I am also curious about The real story behind Wayland and X (Daniel Stone). In the final session, probably Building Persona: federated and privacy-sensitive identity for the Web depending on how my conference energy is going.

And then where?

I’m headed back to the USA in March for PyCon, and I’m looking forward to having way (waaaaaay) less commitments than I did at Wikimania 2012, and therefore being able to catch more of the talks. And not dragging myself to my hotel room at 4pm to order crème brûlée room service because I am too tired to figure out how to work the lifts. (It was good crème brûlée though!) The Ada Initiative will probably be running some non-talk activities though, so it won’t be wall-to-wall talks. And then a second return to the USA for AdaCamp SF. And that really might be enough for one year, but if not, there’s always Kiwicon.

Fun at LCA 2013: my picks for Tuesday and Wednesday

I’m currently regarding LCA 2013 as my last LCA for a while. Never say never: LCA 2014 bids came in from Sydney (so, local to me) and Perth (where I’ve never been and would like to go). But I first went to LCA in 2001 and then later went to 2004 and since 2007 I’ve been to LCA every year, except for 2010 and that only because I had a baby in the middle of the conference.

LCA used to be my main way of reconnecting with open source while I was working on my PhD. But now I work for the Ada Initiative and open source (and open stuff) events are a big part of my job. While I have more time and energy for conferences I am attending them for very different reasons now and the lure of the new is getting strong.

Because my volunteer time is diminishing, LCA 2013 is definitely the last LCA in which I will have had significant input into the program (Michael Davies and I are co-chairs of the conference program this year, as we were for 2010). So, it’s something of a farewell tour for me and I’m looking forward to the program we worked so hard putting together.

Monday

… actually my non-LCA-ing family is still in town Monday, so I’ll probably go to Bdale Garbee’s keynote and then hang out with them. Off to a great start here, I know.

Tuesday

Radia Perlman’s keynote is the keynote I am most looking forward to this year. Following that several of my peeps are giving Haecksen talks before lunch:

  • Feminism, anarchism and FOSS – Skye Croeser
  • Overcoming imposter syndrome – Denise Paolucci
  • Security – Joh Pirie-Clarke

People may be especially interested in the Imposter Syndrome talk, Imposter Syndrome being the feeling that you’ve achieved your current position or status totally fraudulently and are going to be discovered any second and publicly humiliated. It’s very common among people who are in quite critical fields (like academia). Denise was among our Imposter Syndrome facilitators for AdaCamp DC.

I am not sure after lunch, but Web Animations: unifying CSS Transitions, CSS Animations, and SVG (Shane Stephens) is a definite contender. In the afternoon The Horrible History of Web Development (Daniel Nadasi) sounds interesting (although it’s the kind of talk where an abstract would be really useful in determining whether I want to go) but so do What we can learn from Erlang (Tim McNamara) and Concurrent Programming is not so difficult (Daniel Bryan)

Wednesday
Trinity: A Linux kernel fuzz tester (and then some) (Dave Jones) is very tempting in the first slot, but I think I will go to Think, Create & Critique Design (Andy Fitzsimon) because I want to “speak” design semiotics a little bit better and have for a long time. Talking to graphic designers is actually part of my job.

In the second slot I am not entirely sure, but probably Open Source and Open Data for Humanitarian Response with OpenStreetMap (Kate Chapman) since I periodically dabble in OpenStreetMap.

After lunch my pick is definitely Free and open source software and activism (Sky Croeser). I’ve been following Sky’s activism and research since the EFA lamb roast fun and met her at AdaCamp Melbourne. I want to hear what she has to say about (h)ac(k)tavism.

Not as sure about the following slot (in a moment of mischief, we put the DSD’s talk right after Sky’s, but I’m not especially interested) but the biggest contender is The future of non-volatile memory (Matthew Wilcox) because he usually is one of the highlights of the LCA lower-level technical talks.

The first slot after afternoon tea I am not committing, but it does contain Pia’s grand scheme Geeks rule over kings – the Distributed Democracy. After that I think Copyright’s Dark Clouds: Optus v NRL (Ben Powell) is required: it isn’t LCA without emerging feeling distinctly gloomy about the current state of the intellectual property framework.

2012: resume fodder

Because I had quite a difficult year in several respects, especially health-wise, some short notes on my 2012 accomplishments.

Total eclipse, partially obscured by cloud
by Flickr user 130GT

Ran AdaCamp. AdaCamp is really originally my baby and AdaCamp Melbourne was significantly my work (with Val, and Skud as local organiser). AdaCamp DC was significantly less so (because I was on study leave between March and May), but still, even on the day they’re a lot of work.

Delivered three talks at linux.conf.au. We gave an Ada Initiative update and an allies workshop at the Haecksen miniconf and our Women in open technology and culture worldwide talk at the conference proper.

Submitted PhD thesis. This was, of course, the end of a huge project. I enrolled in March 2006 and was full-time until December 2009. I was then enrolled part-time from July 2010 (after maternity leave) until May 2012 when I submitted the thesis. The submitted version is 201 pages long, word count is difficult with LaTeX.

Delivered the keynote address at Wikimania. This is to date my largest ever audience, I think.

Saw a total solar eclipse. Less of the work, just as much reward. The photograph of the eclipse shown here isn’t mine, and isn’t exactly like our view (we saw the top rather than the bottom through our bank of cloud) but it’s also from Port Douglas, and is very similar.

Why is someone’s entire adult life relevant to their job application?

This article originally appeared on Geek Feminism.

Over at Captain Awkward’s advice column, there’s a question about how to deal with a recent name change when potential employees may call references that know you by a former name. The advice moves a little into how to deal with “resume gaps” in general:

Prospective employers will ask difficult questions about gaps in employment, changes of field, etc., but often they are doing it because they want to see how you react to the question before they decide if it is an actual issue. They want to make sure that you didn’t lie on your resume. They want to see if you have a coherent reason for whatever it is. And they want to see if you react with grace under pressure, or if you turn into a defensive weirdo… [P]lenty of people take time out of the workforce to care for kids, go to school, look after aging relatives, etc. and then are in the position of trying to get back into the workforce. If an employer is going to hold your years as a caregiver or student against you in making a hiring decision, that is their bad. Do not apologize! Do not talk about how your skills are “rusty”! If they say “I notice it’s been a few years since you’ve been working in this field, what’s up with that?” say “Yes, I was lucky enough to be able to take some time off to care for my mom at the end of her life,” or “Given the cost of day care, it made sense for one of us to stay home with the kids for a while” or “Yes, it was strange to be a grad student-by-day, bartender-by-night, but my customers were great and I learned a lot from having such a public-oriented position” and then ask a question about the position at hand.

It’s possible to disagree for pragmatic reasons with the advice to disclose here (see for example annalee’s comment on that post), but I wanted to move away from the question of what individual jobseekers should do — to be clear: I don’t fault Captain Awkward discussing that, it’s an advice column! — to the general question of why this comes up. Why do resume gaps matter, exactly? Why is a job candidate who has several unexplained years on their resume a worse candidate for a job?

Here’s my hunch about why it matters: because it’s a proxy for discriminating against (former or currently) ill or disabled people and carers, pretty much. And people with a history of institutionalisation, and others. So at an individual level you can disclose on the principle that while it sucks that there are powerful bigoted people out there, it’s better to find out that they’re bigoted against you before you’re working for them. Or you can not disclose on the principle that while it sucks that there are powerful bigoted people out there, you might be able to stay mostly under their radar when you are working for them. Not the most excellent choice in the world!

This seems in some ways hackable to me. This isn’t a new insight, but part of the problem with hiring is the need to choose one person (or N people), and, typically, having more than N applicants. You need some tools to eliminate people, so people come up with petty absolutes about resumes that are in the wrong font, or are one page long, or aren’t one page long, or that cover letters that use “I am writing to apply for” rather than “I am applying for” or whatever you like. And of course it’s easy to fall into bigotry too. The ideal worker bee is young and male and “flexible” and so on. If society has squashed someone down by keeping them out of the workforce, you don’t want your organization to have to pay the price for the squashing, so let’s require an age-21-to-present-time employment history too. Some people have that, after all.

There’s a real problem with resume gaps, which is that they might be actually relevant time that the person doesn’t want to talk about with you (for example, the employer they defrauded), but I think it’s at least worth questioning the idea of pushing down on everyone who has ever been out of the workforce in order to find them, and there’s definitely also a desire to ferret out “flakes” (people who you want to discriminate against) among some employers.

One possibility then is that by consciously letting go of the idea that your hiring skills guarantee getting the single best hire, or the belief that your resume filtering skills and interviewing skills are helping you past a certain point, and choosing randomly from the best M applicants as selected by your hopefully-consciously-avoiding-bigotry hiring process. And by letting go of your belief that you need total control in order to select The One, perhaps you can let go of at least some received wisdom about seeing “red flags” in any sign that someone may have done something with their weekdays other than work, and that they may not want to talk to you about that.

What received truths of hiring do you think are bogus or discriminatory?