K.Tierney

2025, by the books

2026-01-01T00:00:00+00:00

For most of the decades I was childless, I read an average of a book a week. I use LibraryThing to catalog my reading.

Since 2022 I have fallen far, far short of that cadence—and, rather uncoincidentally, haven’t updated this blog either. In 2022, I read 8 books in total. The longest of these was JR by William Gaddis at 752 pages, a book I have started and failed to finish many times over the years.

In 2023, I doubled this count and read 16 books. All quite short, easy reads, but I was starting to get my groove back, so to speak. The last book I read in 2023 was finished at the start of October, just before I started work at Intercom. I read nothing in the ensuing 6 months, instead working myself to the brink of burnout and beyond the point of exhaustion.

In 2024, I changed jobs again and read 12 books in the year. An average of a book a month, but my reading was front-loaded and primarily happened in the second quarter of the year, before I became once again immersed in work. The longest of these was Salt, a nonfiction book by Mark Kurlansky of 496 pages about the history of well, salt. It was, shall we say, a bit dry? I’m not a big nonfiction reader. If it’s not work-related, I struggle to get through it and often will not finish.

So in comparison, 2025 has been a blissful respite. No job changes, no major life milestones to navigate. It’s been a quiet year, despite changing teams twice at work and pushing through some quite chunky technical projects, and parenting a high-energy toddler. I read 16 books, but two of those were 3-in-1 trilogies (the Sweetpea series, and Ursula K LeGuin’s Three Hainish Novels), so in a certain light, if you squint a bit, we can call it an even 20. Well, 21 once you factor in the O’Reilly-published book I acted as a tech reviewer for! And if for some reason you were to count re-reads and kids’ books, my Read Count for the year would probably be multiplied by a factor of 30. The longest book I read this year was Robert A Caro’s masterpiece work on Robert Moses, The Power Broker, at 1344 pages. I finished it in August and promptly took a three month break from reading anything at all.

I continued to draw lots of reading-related inspiration from Mandy Brown’s blog A Working Library. This year, a lot of my reading was also inspired by Remy Sharp (thanks, Remy!). I am, as ever, always on the lookout for recommendations that can help me get back into the swing of things. Although 2026 will be another very slow year for books for me, I expect, as we’re expecting our second child midway through the year!

Reflections on another year gone by

2021-12-31T00:00:00+00:00

I haven’t posted much this year. I didn’t read many books, falling far short of the weekly cadence I’ve maintained for years running. I didn’t go on a single proper holiday, making this the first year in decades in which I had no real break to reset. I tried to keep up with new music releases from the genres and artists I enjoy, but didn’t succeed—my “to listen” list is dozens of albums long. I hardly saw or spoke to friends, didn’t text back, didn’t reach out. In a lot of ways, it feels as though I didn’t do much at all. Even compared with 2020, an intense year by any standard for damn near everyone, I did a poor job of staying on top of the things I usually try to stay on top of.

It’s the end of 2021. My usual stats (countries visited, books read) don’t reflect the year I had, but it’s still a good time for reflection.

So what did I do this year?

1. Ceramics

I made a lot of functional ceramic art! In all, I made more than 50 new pieces this year, including many bowls, plant pots, some vases, and even a few small plates. I cataloged most of them on a new website. It’s not a completely exhaustive list, since I gave away quite a few before starting the catalog, but I’m excited to have a record of my work to see how it improves over time. I’ve improved my skills a lot, but still have much to learn. I took two pottery courses this year: a four-day intensive wheel-throwing course at Jess Jos studio in Stepney Green, and an 8-week course with Turning Earth using hand-building and throwing techniques. I signed up for a monthly membership at Turning Earth, which allows me to visit the studio near my home and work at my own pace. For me, the experience of working with clay is meditative and relaxing. I like working with my hands, and I think it’s good for my mind (and my eyes!) to spend a few hours a week away from computer screens.

2. Plants

In a similar vein, I spent a lot of time caring for my house plants this year. I attempted some more ambitious gardening projects, planting seeds in the late winter/early spring for a variety of herbs and peppers, and tended them assiduously, but ultimately didn’t have much success. I fought tooth and nail to keep the aphids at bay, but the plants remained small, sickly, spindly, and I only harvested the tiniest handful of peppers at the end of the season. I weeded and refreshed the flower bed outside my front door, planting a whole bed full of ranunculus, lavender, and rosemary but they all disintegrated. Our flat is in a very shady courtyard. I think this experience taught me an important lesson about hubris and acceptance of circumstances, so I won’t make the same mistake next year. I had more luck in propagating the houseplants that have thrived over the past few years, and distributed many monstera, pothos, tradescantia, sansiveria, zz plant, and pilea to pretty much anyone who came through. At one point there were well over 100 plants in this tiny flat. With the winter, I’ve managed to pare down to around 75. It’s still too many.

3. Health, sort of

I kept up regular visits to my gym, doing mostly pilates, yoga, and boxing. I’m pretty sure I caught COVID at the gym. I was lucky to have a mild breakthrough case, to test myself early, and managed to avoid exposing anyone outside my household. That’s really about the best any of us can ask for, I think. My husband, in his eminent wisdom, took a third vaccine dose in the weeks before I was exposed. He remained uninfected, despite not even making a half-hearted attempt to isolate from me during my illness. Our flat is too tiny; it would have been pointless and ineffective. The vaccines work well for those that receive them, which is good news.

4. Work

I started a new job in January, after taking time off last year to recover from burnout and try to learn to live in a pandemic society. The path to burnout recovery is long, winding, and mostly uphill. I had a few backslides, using holiday time to reset during the lockdowns and to pay an overdue visit to our family in the USA, instead of to take any real holidays. I have a tendency to immerse myself in work as a distraction from the rest of the world, and sometimes this approach isn’t the best for my mental health. Despite this, I did some good work. I was hired as the company was levelling current staff in accordance with a new progression framework, and had my senior level confirmed at my first review, and was promoted to staff engineer six months later. I’m not alone in struggling to find a work/life balance that’s sustainable for pandemic living. Myself, and both of my Platform Engineering teammates, will be moving to a 4-day work-week in 2022 (an 80% contract, not four long days).

5. Sustenance

I bought a new refrigerator. Not to be all “woo consumerism” but after living with the tiny dorm-style under-counter fridge that’s ubiquitous in London flats, having a real American fridge, even a small, cheap one, has been a huge quality-of-life improvement. With all of the pandemic lockdowns, we spent a lot of time at home this year. Being able to do shopping for more than a couple of days at a time, and to fill the fridge with fresh produce and cold drinks, made a big positive difference for us. It also allowed us to take advantage of some of the great at-home meal kits put together by our favourite London restaurants during the lockdowns.

Just the hits

I did read some books, just not as many as usual. I read a lot of articles and blog posts. I watched a lot of television shows. Some of my favourites:

Happiness: A novel by Aminata Forna
Gods of Jade and Shadow by Silvia Moreno-Garcia
Detransition, Baby by Torrey Peters
A Fine Balance by Rohinton Mistry
Miss Buncle’s Book by D.E. Stevenson
I’m watching a lot of The Expanse, and it is very good. I haven’t dipped my toe into the extended literary universe yet but it’s probably just a matter of time.
I’m rewatching Halt and Catch Fire now that I’ve finally convinced Adam to watch it. Still very good.
The final series of Insecure did not disappoint. One of the best soundtracks of any show on TV too.
Star Trek: Lower Decks continues to be far better than it has any right to be, the best and most Star Trek of any recent ST series.
Summer of Soul is maybe the best film I saw all year. I don’t watch a lot of films, but this one is very good, go watch it.
I use Feedbin + Reeder for most of my internet reading. This year my most-starred blogs were pretty reflective of the work-immersion: Lara Hogan, Julia Evans. I’m enjoying Roxane Gay’s newsletter and Nikesh Shukla’s writing about writing.

Here’s a random sampling of some songs I liked that were released this year, too:

Remembering Martin Andert

2021-02-02T00:00:00+00:00

Content warning: death, psychological trauma, and thoughts of self-harm

Martin Andert died last week.

Unless you worked with him, you probably didn’t know Martin Andert. He was an excellent software engineer, but he didn’t have a blog or personal website. His Twitter account offered no original content, but he bestowed approval with the occasional fave or retweet, made all the more precious by scarcity. His Github profile reveals a dedication to his work and a lively interest in extracurricular coding, despite being very busy with his full-time work.

He lived in Germany, and leaves behind a family who I can only guess will miss him very much. I’ve seen photos of them, but I don’t know their names. I’m told they don’t speak English.

I only met him twice in person, but I also miss him very much. I was devastated to learn of his death. I read the messages on my phone, logged off from work, and went into the kitchen where my husband was working. As he tried to wave me away without looking up—he was busy, I was interrupting, I knew—the tears welling up in my eyes quickly turned into full-on hiccuping ugly crying. (Don’t worry, I was quickly enveloped in a hug as soon as he looked up and noticed my distress.)

I don’t think I reacted that way when my grandparents, who I adored, died. Nor when my uncle passed away unexpectedly at a young age, in the middle of the night, just as Martin did. When I cry, it’s generally a silent, stoic sort of crying. And yet. There I was, sobbing in my kitchen. Martin is dead, I wailed. I’m writing this a few days later, and still sometimes my heart protests against this fact, a wave of raw emotion overtakes me.

We were friendly, but we weren’t friends. We were colleagues for a short time—less than two years—but in that time he had a profound impact on my life. He was a private person. Our conversations, while warm and engaging, touched only on matters related to our work together. In many ways, I hardly knew him.

There are some things I do know.

Martin was a careful, meticulous developer. He held himself and everyone around him to a high standard and took great pride in his work. Drawing on his background as a designer, he took as much care in crafting clear and navigable user interfaces as he did in crafting an abstract syntax tree for custom linting rules to help enforce his high standards across our codebases. He was difficult to please, known for rigorous and thorough code review. He wasn’t one to dole out superfluous or unearned praise.

Early in our time working together, Martin told me I was a good engineer. Later, he told me I was a good manager. Both pieces of feedback were unsolicited, and certainly sincere and straightforward; I didn’t know him to communicate in any other way. Others have been much more effusive in their praise of my skills, but knowing that Martin thought I was doing a good job was an evaluation I could reflect back at myself on low days. “Look, Kaitlyn, you can’t be as crap as you feel because even Martin thinks you’re doing a good job.”

There were many, many low days. So this came up more often than you might think.

I haven’t spoken much publicly about my time at Rail Europe. I posted a few tweets, I was threatened by someone from human resources, I deleted them (mostly). On my timeline, you’ll see I was an engineer, and then I was a manager, and then I returned to being an engineer. This was my choice, but my supervisor still had me sign a letter titled “demotion”. I signed another letter promising not to quit for a year. A few months later, I volunteered for redundancy, damn near begged for it, as soon as the pandemic started and it became obvious that the management weren’t taking care to cut costs, were sharing ludicrously optimistic financial projections out of line with any potential reality. I knew there would be deep cuts on my team, and I didn’t want to stay behind and bear the burden. Martin did, and I worried about him, but I’ve heard he was happy enough there towards the end, and I was relieved to learn that.

“Burnout” is a term that’s thrown around a lot in the tech industry. Rail Europe burned out many good people. I’ve never experienced it before, so I’m not sure if the trauma I experienced at Rail Europe was a form of burnout, or something different. I’ve lived with depression my entire life, so when I found myself spending large parts of each day and night fantasising about killing myself it didn’t feel uncomfortable or surprising. It wasn’t a warning sign. It’s only now, in the midst of a pandemic, when I haven’t seen my family and friends in over a year and I’ve lost all of my mental health coping mechanisms (going to the gym, making pottery, traveling), while I’m working again at a challenging job, that I can put my finger on it: trauma. I’m not fine, I’ll probably always have depression, but I haven’t fantasised about suicide in months. My confidence, my resilience, are still shattered from the trauma of my experience at Rail Europe.

During those dark days, there were many times when a kind word or conversation with Martin provided the tiny kernel of validation, of appreciation, that I needed to continue. To continue working, sure, but also to continue showing up, living. If you could call what I was doing at that time “living”, which, I’m not sure.

When someone dies shockingly, suddenly, sometimes we regret the things unsaid, the opportunities missed that can’t be made up. But although we hadn’t spoken for a few months, I don’t have any regrets with regard to Martin. I was effusive in voicing my admiration for him, both to him directly and, as his manager, to those higher-up to ensure he received recognition for his contributions. I supported him unwaveringly, as he did me, as many of our other colleagues from that time did for us both. There are many different ways to live in this world, many ways to show up for people. Martin was pleasant, professional, able to keep his work life and personal life wholly separate, but that didn’t diminish his impact. He showed up, he did the work. He taught me a lot, and he will be missed.

Your Hiring Process Is Probably Biased

2021-01-04T00:00:00+00:00

Hiring is hard and important.

Hiring is hard. This is true in any industry, but in the tech industry we’re in the habit of handing out life-changing salaries to people who have bootstrapped their own careers. With our hiring choices, we have the power to reshape the financial reality for people from marginalised backgrounds or impoverished communities.

It’s not uncommon for skilled developers to be neurodivergent, or to struggle with mental illness. For many people, mental health problems have been exacerbated by years of abusive treatment within the industry, or by burnout. As a hiring manager, you have a duty to care for the people you interact with. At a minimum, your hiring process should not actively hinder people’s well-being and mental health. When successful, your hiring process is a critical step to building a high-performing engineering team and a great product. When done badly, you’ll burn your reputation and you’ll struggle to recruit, or you’ll find yourself only recruiting people who resemble your current (likely homogeneous) team.

You are not entitled to good candidates

This post is for engineering managers, technical founders, engineers who aspire to become managers one day—for anyone with the responsibility of hiring software developers at a small to mid-sized company. It contains strong opinions, anecdotal examples of actual hiring processes I have endured, and quite a lot of advice for ways you might be able to improve your hiring.

Of course, my idea of a better hiring process might not be the same as yours. If you don’t agree that diverse teams build better products, you’ve found yourself in the wrong place. Please move along. I’m not here to sell you on the importance of diversity, and you have bigger problems to sort out than your broken hiring process. You can try to build a diverse team within an organisation that doesn’t value diversity, but it won’t be sustainable and you’ll risk recruiting wonderful engineers and then giving them a bad experience. Please don’t do that. I’ve made that mistake, and I can assure you, it feels terrible. If anyone from HR or your executive team says the words, “It’s a pipeline problem,” to you, just run as quickly as you can into the arms of a new and better employer.

The goal is simple

Healthy hiring has a simple goal: to enable candidates to show you their best work, so that you can try to assess whether they’ll be able to perform the job responsibilities, and so that they can assess whether they’d like to work with you.

Brittle == biased

Hiring can be conducted on a rolling basis—you have many openings to fill and a good runway to pay them—or what I like to think of as “high-stakes hiring”—you have one or two immediate openings, and must select the best candidate(s) from a pool of people who have applied during a fixed time period. The process is basically the same for both, but your feedback loop is longer for a high-stakes hiring event, since you won’t be able to enact improvements to your process until your next hiring round. With rolling hiring, your process can evolve and improve over time as you learn from the feedback candidates provide to you.

Building a good hiring process follows the same cycle as building a good product: Build, measure, learn. But how do you make sure you’re building the right thing? Who is your hiring process optimised for? One size doesn’t fit all—not for socks, not for t-shirts, and especially not for assessing the diverse range of skills and capabilities that make for a good software engineer.

Most hiring processes for software engineers are divided up into a few rounds, or phases. There’s some sort of intake procedure, a sifting or screening process, often performed by an algorithm or a low-level HR employee or support staff. There’s likely to be one or more technical assessment rounds. There will almost certainly be some sort of interview delving into a candidate’s past experience, and often an additional interview to evaluate “culture fit”. These stages can drag on for weeks, even months, or can be pushed through in less than a week. Sometimes the timing is flexible, while the steps followed are not. Bias creeps in at each stage of the process, and it’s easy to lose sight of the goal.

If your hiring process isn’t flexible, you’re defaulting to optimising for a certain type of candidate. Is that really what’s best for your business? Is this a choice you’ve made, or a trap you’ve fallen into? Consider the wide range of people you might be excluding, and the valuable perspectives they could be bringing to your product development:

People with mental illness (anxiety, depression)
Neurodivergent people (autism spectrum, ADHD, etc.)
People from nontraditional backgrounds, who may have job-relevant skills but, if they don’t job-hop or interview a lot, may not yet have gained the specific interview skills you’re expecting them to exercise
People of lower socioeconomic status, for whom performing unpaid timely labour (completing your hiring process) may not be feasible
People with carer responsibilities, more than full-time work, or other time and availability constraints
People with disabilities, and if you haven’t offered suitable accommodation, this may be illegal in your country

Sifting and screening

You probably don’t have time to interview every candidate who applies for a job at your organisation. And you might not want to, even if you have time—copy & paste cover letters are common, and some folks clearly take a firehose approach to job applications, especially if your application software offers a 1-click “import my data from LinkedIn to apply” button. This initial screening, to hand-pick the candidates who might be a good fit based on their CV and cover letter, is frequently performed by people far removed from the rest of the hiring process. I can’t tell you how many stories I’ve heard from hiring managers who received a stack of 40 CVs for an open role, filtered by their HR department, only to discover that everyone who wasn’t a white man had been filtered out.

It’s also a measurable, proven source of bias and discrimination in hiring. It’s totally unnecessary, unhelpful, and you should skip it and do something better. And I say this as someone who almost always, 99 times out of 100, will get through this initial screening due to my penchant for writing a persuasive cover letter. This process is clearly biased in my favour and I’m still telling you straight-up that it is bad and toxic and you shouldn’t do it.

This is not an advertisement for Applied, but I had the opportunity recently to use the Applied platform as a candidate and see for myself what their sifting process is like. It’s fantastic. Candidates are presented with a slate of questions designed to reveal competencies relevant to the role. Once they’ve submitted their answers to these questions, candidate responses are anonymised and shuffled into random order, presented alongside responses from other candidates for scoring and review. The aggregate of anonymous scores is used as a cut-off to determine which candidates have scored well enough to proceed. During this initial sift, no one responsible for hiring is seeing candidates’ names, educational history, or employment history. Candidates are evaluated solely on their responses to job-relevant questions, which (unsurprisingly) turns out is a far more accurate predictor for success.

In my experience as a candidate with Applied, I was asked questions about web performance, code reviewing broken Javascript, using elasticsearch for analytics and reporting, working in teams, and prioritising work. The questions were thoughtfully designed to reveal a lot about my thought proccess and approach in each of these areas, and I’m confident their team learned a lot more about my skills and knowledge than they would have learned from looking at my CV.

Writing skills are crucial to working well in teams remotely. Writing a cover letter is a skill unto itself, and not one which is generally useful during day-to-day work as an engineer. By asking candidates to provide thoughtful written responses to questions relevant to their work, you’ll be able to evaluate competence at written communication; by doing this anonymously and in randomised order, you’ll ensure that your evaluation is based on salient information instead of the irrelevant background noise to which you’ve been conditioned to pay attention.

Interviewing remotely

Once you’ve identified a few promising candidates from your pool, you’ll contact them to schedule an interview. It’s 2021 and the world is a hellscape, so unless you’re lucky enough to be in New Zealand, South Korea, Taiwan, Australia, or a few other countries with competent governance, you’ll be interviewing remotely over Zoom or Skype or some WebRTC-based video chat tool.

Interviewing remotely sucks. I love remote working, but if given the choice, I’d always choose an in-person interview. For many people, the technology for remote meetings just doesn’t yet compare with the fluidity of IRL conversation. In particular, unreliable upstream internet service can have huge impacts on how a candidate will perform in an interview.

So it sucks, but we have to do it, so we may as well make the best of it. Luckily, with some slight adjustments to your interviewing etiquette you can set your candidates at ease and give everyone a fair chance at success.

Start by making sure everyone can hear and see each other. This can feel a bit awkward, but normalise starting your call with a verbal confirmation that all parties can see and hear one another.
Outline the agenda in advance. You should include a detailed agenda, with the questions you plan to ask, in the calendar invitation for the interview. At the start of the call, review the agenda and outline how the interview will proceed. For example, “The purpose of this call is to get to know you a bit and to allow you to ask questions of us. We’ll start by introducing ourselves, then we’ll talk through the questions we shared in advance. We expect that to take around 20 minutes, which should leave 10 minutes for us to answer any questions you have.”
Score responses to fixed questions. Ask the same questions of each candidate, as much as possible. Define your scoring system and your questions in advance. If you’re hiring on a rolling basis, these questions will change over time. That’s fine. But aim to maintain a consistent approach and ensure that it’s well-documented.
Watch closely for visible signs of packet loss. You’re a technical person. You can see and identify signs of poor connection, high latency, and packet loss. You need to adjust your communication style accordingly, by pausing and repeating yourself as-needed to counteract technical challenges.

Bad connections are inevitable, often outside of our control, and make video meetings an incredibly ineffective and inefficient way to communicate important information. We still do them, because it’s nice to meet someone face-to-face and see how you interact with one another. But the limitations are substantial. Use video calls to augment your knowledge, but do not rely on them as the only means of collecting certain information about a candidate.

One of the best interviews I had was with a company who build a WebRTC-based video chat system. I spoke with two of their engineers, who were on it when it came to noticing packet loss and adjusting the conversation accordingly. Even though the connection wasn’t great, we were able to have a delightful, comfortable conversation by working around the technical difficulties.

One of the worst interviews I had started with, “I’m XXXXX and this is XXXXX. Let’s start with the back-end task. Can you share your screen?” For this interview, I requested an agenda and more information about the nature of the interview in advance, but was told my questions wouldn’t be answered because it “wouldn’t be fair.” This was not a high-stakes hiring situation; the role had been open for months and many recruiters were working to fill it. If you’re relying on your interviews to weed out candidates, or to pit them against one another, you’ve lost sight of the goal. To enable candidates to show you their best work, help them to come prepared, just as they would for a day at work. And for goodness sake, at least start your call with, “Hello, how are you?” and “Can you see and hear me okay?”

Assessing technical competence

Tech tests, coding challenges, technical assessment. Whatever you call it, this is where a lot of places fuck up.

Many companies use a take-home coding challenge as a second-round screening, to eliminate candidates from the funnel who don’t show a particular set of skills in their solution. Congratulations, you’re optimising for people with free time and comfortable socioeconomic status, and you’re placing the burden of evaluation solely on the engineers on your team who are willing to score a coding challenge.

Some hiring managers look at side projects and open-source contributions as a way of assessing technical competence. Congratulations, you’re optimising for people with free time, comfortable socioeconomic status, and who have not been victims of harrassment, abuse, or stalking.

Maybe you prefer to do a technical interview or some pair programming? Congratulations, you’re optimising for people who have taken the time to hone their technical interviewing skills. These skills are not actually very related to the job you’ll be asking them do. You’re effectively eliminating candidates with anxiety, from nontraditional backgrounds, or with some forms of disability. Pair programming is particularly insidious, as it shares a name with a common practice you might engage in at work, but in an interview format it bears no resemblance to the other kind of pair programming you might be familiar with.

There are a lot of different ways to be a good programmer. A person usually only has to be good at one or two of them. Odds are good that you’re testing for skills you don’t need. This may also be preventing you from assessing far more valuable skills that you’re not seeing. To truly assess someone’s technical competence, don’t lose sight of the goal. How can you enable a candidate to show you their best technical work? I don’t know! And you don’t either. The only person who will know how they work best is that specific candidate. This is where a brittle process will fall flat, losing you valuable candidates and poisoning your name if you torment people unnecessarily. Define the skills you’re looking for in advance, and offer your candidates a slate of choices for demonstrating those skills.

Options for technical assessments

Take-home tests
- 👍 Working at home and independently is similar to an actual remote working environment. A well-designed take-home test can allow anxious candidates a good opportunity to show their best work.
- 💰 Can be inaccessible for candidates with care duties and full-time jobs, so your take-home test shouldn’t be a firm requirement. If you must have a candidate complete your take-home test, you need to pay them for their time.
- 🤖 The challenge should be as closely related to your business domain as possible. I have seen challenges to build a vending machine (for an AI-type chat application), to program a robot to move in a certain way (for a fintech company), and to make a 3-card Monty game (for a company doing film analytics). Just…. why. Don’t do this. Don’t do any of this.
- 🛠 Unless you’re hiring a developer for a greenfield project, you’re probably looking for someone who can work well in your existing codebase. So make sure your take-home test includes starter files! Bonus points if you use your actual codebase, or some sanitised portion of it.
- 🔍 Requirements must be clearly defined. No, more clearly than that.
- ⏰ Be mindful of your timing! Particularly in high-stakes hiring, if you’re giving all of your candidates the same take-home test to do over the same time period, you’re a real asshole if you make that time period “the weekend of Rosh Hashanah”. This did happen to me. I don’t think they have any Jews working for them. Probably not too coincidentally, there are also no women on the team this was hiring for.
- 💞 The feedback you provide to candidates should be of comparable quality to what’s shared in an internal code review. This means it should be kind, empathetic, and constructive. If you find yourself providing the same piece of feedback to everyone, that’s a great indicator that your challenge requirements aren’t clear enough.
Technical interviews
- ⚖️ More respectful of candidates’ time, but require skills that are interview-specific, not very related to job duties
- 🧩 Can be a good way to demonstrate technical competence in lieu of a take-home test, or to follow up on knowledge gaps potentially evidenced by take-home tests
- 🧠 To get the best performance from candidates, allow them to prepare in advance. A good developer doesn’t go into a meeting unprepared. Why are you screening for people who excel at doing that? It’s far more interesting to see how a candidate can approach a problem if they’ve been given some time in advance to think it over and understand the context, particularly for design and architecture problems.
- 💣 I’ve often heard the conventional wisdom that developers should practice their interview skills regularly by going on interviews for jobs we have no intention of taking, or applying for jobs even when we’re happily employed elsewhere. While it’s true that often these interviews, particularly systems design and other technical interviews, generally require practice to do well at, this advice is, frankly, absurd. Going to practice interviews is a waste of everyone’s time, and privileges people who can afford to take time out of their jobs to do this regularly. And bad interview experiences can be psychologically damaging! Practice for the sake of practice doesn’t come without risks. Moreover, the reason these types of interviews require practice is because they don’t exercise skills actually used regularly on the job.
Code review
- 🔑 A trend I’ve been seeing more of lately is to include a code review phase of technical assessment, often as part of a take-home test or interview.
- 🧶 I like this, but it relies on clear requirements to work well. If your take-home code review assessment says something like, “You’re reviewing this code for a colleague,” that raises more questions than it answers. Determining the appropriate tone and content for a code review is highly context-dependent, so you need to make sure candidates have that context.
Trial work day
- ⏳ One place I interviewed used a “practice onboarding day” in lieu of other technical assessment. It’s a good option if you’re in a high-risk hiring situation, where you need to give a fixed number of candidates a deep assessment over a short time period.
- 📅 Sometimes this can be extended; you can offer up to a full week’s worth of trial work if you’re very nervous or unsure.
- ⚡️ You must offer options; this option won’t be accessible to people with full-time jobs if you’re expecting them to do this during regular working hours.
- 💸 Of course, you must pay them.
Side projects or open-source contributions
- 🐙 This is fine if the candidate offers up some code to look at, but bear in mind that it might not tell you what you need to know.
- 🔒 It’s reasonable to use this as a positive measure, but it’s not acceptable to count an absence of side projects or OSS contributions against a candidate.

Feedback and fallout

A bad experience with your hiring process can ruin a person’s week, or even month. You don’t want that kind of ill-will towards your company floating around out there if you can avoid it. (And you can! It’s not that hard to not be awful!) What feels like a good experience to one person might be anxiety-inducing or worse for others. People with mental illness, disabilities, or other constraints have developed strategies to be successful at work, but these strategies don’t necessarily map to the different set of skills required to interview and apply for jobs. By making your hiring process as close to real-life work as possible, you’ll gather more relevant information and stop excluding those candidates who may provide the most value to your organisation.

Over-communicate, and communicate in multiple formats, to align expectations and overcome mismatches in communication style or technical issues.
Provide valuable, constructive feedback to all of your candidates, and listen to their feedback for you.
Offer options and accomodations during each of your hiring stages to enable candidates to show you their best.
Share questions and problems in advance so that candidates can come prepared to dazzle you.

With a bit of effort, you can craft a more inclusive hiring process. Effort expended up-front to make your process more pleasant for everyone will pay dividends in diverse teams of people who feel valued and supported, and who are empowered to do their best work for you. Good luck!

2020 in Books

2020-12-27T00:00:00+00:00

I read an average of a book a week. I use LibraryThing to catalog my reading.

These are the 52 books I read in 2020.

Watchmen by Alan Moore
User Story Mapping: Discover the Whole Story, Build the Right Product by Jeff Patton
Rusty Brown by Chris Ware
Queenie by Candice Carty-Williams
The Overstory: A Novel by Richard Powers
Difficult Conversations: How to Discuss What Matters Most by Douglas Stone
Miss Pettigrew Lives for a Day by Winifred Watson
The Broom of the System by David Foster Wallace
On Earth We're Briefly Gorgeous: A Novel by Ocean Vuong
Because Internet: Understanding the New Rules of Language by Gretchen McCulloch
Bird by Bird: Some Instructions on Writing and Life by Anne Lamott
Every Eye by Isobel English
Eloquent Javascript, 3rd Edition: A Modern Introduction to Programming by Marijn Haverbeke
Black Leopard, Red Wolf: Dark Star Trilogy Book 1 by Marlon James
Mason & Dixon: A Novel by Thomas Pynchon
Hauntings, fantastic stories by Vernon Lee
Her Smoke Rose Up Forever by James Tiptree Jr
Writing Down the Bones: Freeing the Writer Within by Natalie Goldberg
Climbing the Mango Trees: A Memoir of a Childhood in India by Madhur Jaffrey
The War of Art: Break Through the Blocks and Win Your Inner Creative Battles by Steven Pressfield
Q & A by Vikas Swarup
The Parking Lot Attendant by Nafkote Tamirat
The Nickel Boys by Colson Whitehead
Fates and Furies by Lauren Groff
A Little Life by Hanya Yanagihara
A Suitable Boy by Vikram Seth
Reading Like a Writer: A Guide for People Who Love Books and for Those Who Want to Write Them by Francine Prose
On Writing by Stephen King
Flush: A Biography by Virginia Woolf
In the Dream House: A Memoir by Carmen Maria Machado
Trick Mirror: Reflections on Self-Delusion by Jia Tolentino
Night Moves by Jessica Hopper
Brown Girl in the Ring by Nalo Hopkinson
Reuben Sachs by Amy Levy
The Runaway by Elizabeth Anna Hart
Tea with Mr.Rochester by Frances Towers
Thanks for the Feedback: The Science and Art of Receiving Feedback Well by Douglas Stone
A Lady and Her Husband by Amber Reeves
Half of a Yellow Sun by Chimamanda Ngozi Adichie
Cherry by Nico Walker
Americanah by Chimamanda Ngozi Adichie
Tender by Sofia Samatar
Into the Woods: A Five-Act Journey Into Story by John Yorke
Earthlings by Sayaka Murata
The Lost Girls of Camp Forevermore by Kim Fu
Disobedience by Naomi Alderman
Do Not Say We Have Nothing by Madeleine Thien
Giovanni's Room by James Baldwin
Changing Planes by Ursula K. Le Guin
Fever Dream by Samanta Schweblin
Homegoing by Yaa Gyasi
Secrets and Lies by Selena Montgomery

2020 in Music

2020-12-01T00:00:00+00:00

Just a whole bunch of music released in 2020 year that made me feel some type of way. If I’ve missed anything you think I’d love, feel free to get in touch.

Songs

A Spotify playlist of songs I listened to over and over

Albums(ish)

A list of albums, compilations, EPs, mixtapes, etc., with links to Bandcamp pages or to Spotify.

We Saw Blue by Oceanator
We Saw Blue by Ley Line
Your Most Secret Name (Selected Songs 2008-2011) by Twig Palace
Tell Me Your Mind and I'll Tell You Mine (EP) by King Hannah

I love this for writing sad stories
color theory by Soccer Mommy
Auto by Wendy Eisenberg
Good News by Megan Thee Stallion
Hypoluxo by Hypoluxo
Ah! (etc) by Kelly Stoltz
Konke by Seba Kaapstad
AN ALBUM CALLED CLASSIC by RU$H, Tha God Fahim, Jay Nice
Free Now by Drew Citron
Pass Like Pollen by Cartalk
Fly Moon Die Soon by Takuya Kuroda
Spilligion by Spillage Village
Concorde by Le Couleur
Do the Duvet by Naked Roommate
Detroit 2 by Big Sean
Bully by SUGAREGG
I'm Glad We're Friends by thank you, im sorry
KIND by Thanya Iyer
Wu Hen by Kamaal Williams
Untenable by BAD MOVES
NO DREAM by Jeff Rosenstock
KRAZY KARL by NNAMDÏ
Love + Light by Daniel Avery
Coriky by Coriky
technicolor by covet
Annual by Modern Nature
High January by Marker Starling
Fine Forever by Varsity
A Hopeless Noise by Red Mass
Everything is Beautiful by Princess Nokia
Disco Volador by The Orielles
Suddenly by Caribou
Likewise by Frances Quinlan
Suga (EP) by Megan Thee Stallion
Sixteen Oceans by Four Tet
Industry Games by Chika
Empty Country by Empty Country
3.15.20 by Childish Gambino
Future Nostalgia by Dua Lipa

The album I listened to most while shaking my booty in the kitchen, cooking up elaborate quarantine meals or making sourdough bread.
Las Kellies by Suck This Tangerine
BRAT by NNAMDÏ
It Is What It Is by Thundercat
The Don Of Diamond Dreams by Shabazz Palaces
Morning Matters by Yazmin Lacey
You Become the Mountain by Jeffrey Silverstein
Innocent Country 2 by Quelle Chris and Chris Keys
Alphabetland by X
Taken Away by Moodymann
Keleketla! Remixes by Keleketla! and buncha other people

Good listening for all of the 2020 activities: sitting at my desk programming or drawing or studying or writing, dancing around my house vacuuming, and putting away laundry. Proceeds from the release will go to the Free West Papua Campaign.

Chex Mix: A Family History

2019-11-16T00:00:00+00:00

Always small for my age, I was never a gluttonous child. I was greedy, yes, undeniably so. By —the kind of bratty big sister who would cut the cake into two vastly unequitable slices and intimidate my little sister into selecting the smaller one any time my parents defaulted to the hypothetically fair and balanced “one child cuts, the other picks” approach to dessert distribution. But I was simply too small and too picky of an eater to ever veer into gluttony.

There were—there are—two exceptions. Special cases, if you will.

Case Number One: My grandmother’s matzo ball soup, aka Jewish penicillin, which inspired a years-long unspoken rivalry between me and my cousin. Who could consume the most matzo balls? Did we really love matzo balls that much, or was eating 20 or more in one sitting an easy shorthand to show to our grandmother how much we loved and appreciated her? These days, my matzo balls are as good as hers were, but without my affectionate Granmma to refill my bowl I never eat more than a few at a time.

Case Number Two: My grandfather’s Chex mix, a fixture at my dad’s parents’ house for Christmas, and usually other major holidays as well. Each year I’d sit near the Christmas tree and sneak handfuls of Chex mix out of the snack bowls on each side table, rotating bowls around the room to keep the ratios even as I picked around the nuts and carefully selected my preferred Chex and pretzels. I’d do this until someone noticed and yelled at me, or complained to my parents.

After my grandpa died, we had a couple of Christmases without any Chex mix. Eventually my dad started making it, experimenting with the family recipe. Spicy chex mix? Sure, of course. Throw some Arrogant Bastard in there? Why the hell not… for years after he discovered Stone Brewery down the road from his house, he pretty much put Arrogant Bastard into everything, as I recall. The recipe I use nowadays is a mish-mash of my grandpa’s original recipe, my dad’s modifications, and my own slight tweaks. But my dad continues to experiment, so his version is invariably better year after year.

“Dad’s Revised Party Mix”

The updated original

1 box each (12 cups)
- rice chex
- wheat chex
- corn chex
- Cheerios
- Cheeze-It
14 to 20 oz small pretzel sticks
2.5 Lbs mix nuts
1 1/4 C melted butter, margarine, or Smart Balance
1 C Soy Sauce
1 C Worcestershire or vegetarian Worcestershire
2 T seasoned salt (optional)
3 T garlic powder
3 T onion powder
3 T celery salt

Bake 250 degrees for 2 hour, stir every 15 minutes.

“Dad’s Party Mix - for Kaiti December 2018 Recipe”

Last year’s Christmas shipment ❤️

Dry Ingredients

14 oz Wheat Chex
12 oz Rice Chex
12 oz Corn Chex
20 oz Cheerios
24 oz Cheese-Its
16 oz Bag of stick pretzels
24 oz Blue Diamond Smokehouse almonds

Sauce

Combine in a pot and heat until the butter melts:

1/4 Cup of each:
- Garlic Powder
- Onion Powder
- Chili Powder
- Smoked Paprika
- Ground black pepper
- Celery Seed
- Season Salt
18.75 Oz Annie’s Organic Vegan Worcestershire Sauce
1 Lb Organic Butter
12 oz Stone Ruination beer

(This liquid is added to thin out the sauce, so it can be spread more evenly, however this also means the finished mixture contains a lot of liquid which now must be dried out slowly.)

Place all the dry ingredients in a large plastic bag and gently mix.
Pour a small amount (~2 cups) into each of several large containers.
Pour the sauce over the dry ingredients in each container using a slotted spoon to help spread the sauce evenly.
Mix the sauce and dry ingredients with a rubber bowl scraper, trying to not crush the dry ingredients.
Continue adding dry ingredients to each container and then adding sauce and then mixing.
Repeat these steps until all the dry ingredients and sauce are mixed.
Place the sauce-covered dry ingredients into a suitable container(s) and bake at 200F to 225F for as long as it takes to completely dry the mixture. This might take 2 to 10 hours depending on how thin the mixture is in the container. If the oven temperature is greater than 225F, the mixture may turn dark brown – which is not good.

Depending on how many nuts are used this makes approximately 4.23 kg or about 9.3 pounds of mix or 40 to 48 cups of dry mix.

Tech-Related Books I’ve Known and Loved

2018-08-28T00:00:00+00:00

Given that I started my career (lo these many years ago) as a research librarian, it’s not much of a surprise that books are my favourite way to learn new things or dig deep into a specific subject. Sure, I spend a lot of time reading blogs, documentation, and academic articles—it can take years to write a book, and I like to keep up with things before they get to the multi-year mark—but for an in-depth exploration of pretty much anything, books are my go-to.

I read, on average, one book a week. It takes me much, much longer than that to get through a book on a technical topic. Since reading a dense technical book is a big investment of time and mental effort, I thought it might be nice to share an abbreviated reading list of programming-related reading I’ve done. If you’re interested in some of the same things that I am, maybe one of the books on this list will inspire you to cozy up with a nice book, a notebook, and a cup of tea.

Two Scoops of Django

For my first professional developer job, I was working with Python + Django. I was learning on the job, but feeling overwhelmed by the sheer volume of things to learn. Two Scoops is the canonical Django guide to best practices, and really helped me get a handle on how Django applications are structured (and why!). I took this on a long train journey across Europe a few weeks after starting my job, and kept it on my desk for reference throughout the rest of my time at the company.

The Well-Grounded Rubyist

Thanks to General Assembly’s Web Development Immersive program, I had a bit of familiarity with Ruby to draw on when I transitioned from full-time Python to full-time Ruby. My first task at Happy Bear was to learn Ruby proficiently by working through some of the Matasano Crypto challenges. The Ruby docs and a lot of searching + Stack Overflow gave me a decent start with understanding bitwise operations, but The Well-Grounded Rubyist taught me how to structure my Ruby code into modules and gave me some much-needed context and detailed explanations of the various methods available in Ruby’s standard library. This book is incredibly well-written and thorough, and I highly recommend it to anyone who wants to learn Ruby well.

The Rails 4 Way/The Rails 5 Way

I picked up The Rails 4 Way after I’d been working on Rails applications with Happy Bear for a few months. By that time, I’d had the opportunity to work with several different codebases for our clients and had lots of questions about the different approaches and file structures I’d seen. The Rails 4 Way demystified Rails for me. This book is really dense (essentially a glorified/annotated version of the Rails documentation) but as a reference tool it’s indispensable. I’m not sure I’d recommend reading through it cover-to-cover for everybody, but for me at that particular stage in my career, it was revelatory. I put the things I learned into practice immediately, extracting classes into decorators and taking a close look at the initializers and routing set up in all the codebases I worked with. I “learned” Rails with General Assembly, but I really understood Rails after reading this book.

Working with Unix Processes

It’s a common problem for anyone new to working with technology: The more you learn, the more you understand (and feel overwhelmed by!) how much you don’t know. Imposter syndrome has dogged me through almost every job I’ve had, but I felt it particularly acutely when trying to debug problems around threading, server configuration, and memory usage for one of the applications I was responsible for maintaining. Since Ruby is a garbage-collected language, it’s easy to overlook the importance of understanding how forking processes can impact memory allocation. This book covers a lot of ground in a small number of pages. I’d recommend it for anyone interested in working with Ruby on Unix.

High-Performance Browser Networking

High-Performance Browser Networking is not for the faint of heart. It literally took me an entire year to read this book—but, considering it’s 700+ very dense pages of detailed information about networks and protocols, I’m not too ashamed to admit that. Starting with the speed of light and ending with WebRTC and covering everything in between (and I do mean everything), after reading it I’ve internalised an understanding of latency and bandwidth and have a very thorough grasp of how the transition from HTTP 1 to 2.0 is changing the way we develop applications and package assets for the web. I didn’t take detailed notes whilst reading this book—I don’t think I ever would have gotten through it, and I would essentially have been annotating every single page—but I did stuff my brain chock-full of a lot of contextual information that starts coming back to me quickly when I page through it again, or have to look up what UDP stands for for the fifteenth time.

Designing Data-Intensive Applications

I’m currently reading this, and it’s an utter delight so far. Author Martin Kleppmann has taken on the Sisyphisian job of collecting and sifting through thousands of resources, from documentation, blog posts, academic articles, and books, covering the past several decades of computing, and he’s somehow managed to collate all of these sources into an eloquent and informative read. I can tell this is going to be another one that will take me a long time to get through, but reading it is sure to be an enjoyable experience and the information it contains will serve me well for decades.

Easy Reading

I’m not always in the mood to knuckle down with a dense technical book, but sometimes I want something a bit less fluffy than a novel. I’ve read a couple of books about developing software with easy, approachable prose—some light summer beach reading, if you will.

Dreaming in Code

An entertaining read detailing the software development process—part narrative, part case study, this book does a great job of making the process of building high-quality software seem impossible.

The Lean Startup

Maybe it’s because I spent so much of my career in established, long-running industries like libraries, or universities, but I really chafe against the jargon of product management approaches. Any time someone around me starts throwing out the words “agile”, “lean”, “kanban” I have to physically suppress my eyes from rolling out of my head. I’m sorry, I can’t help it. It’s so clear that iterating quickly and putting users first is the best approach for developing useful products that I find it hard to believe there was ever another way of doing this, or that we needed a manifesto written by a group of cis white men in order to land on it. The Lean Startup describes a way of defining and building products that is so eminently sensible it’s become a must-read for every start-up founder, but it’s a great read even if you’re not planning to go start your own company.

One Year of Going For It

2017-06-27T00:00:00+00:00

Today marks one year since I walked into General Assembly’s fresh new Aldgate East campus for the first time, bright-eyed and bushy-tailed and ready to throw all of my money and three months of my time behind one singular goal: Get a decent job in London.

In as much as there is a typical profile (there probably isn’t), I never really thought I’d be a likely coding bootcamp alum. I’ve been making websites most of my life, teaching myself HTML and CSS by snooping code from other sites before I really knew what “code” even was. Much later on, I took courses covering basic HTML, CSS, XML, SQL, all for my graduate degree in library & information science. I knew as much code as I needed to do my job well, and was comfortable enough with it to poke around and build things (or modify existing things to suit my tastes) in Wordpress, Joomla, Drupal, and whatever else people were using.

And yet, jumping from that level of technical ability to actually being a professional developer seemed impossibly daunting. Somewhere down the road, perhaps while I was spending my early 20s becoming a terrific but completely unemployable librarian (inasmuch as nearly any librarian is unemployable these days, thanks to the economics of supporting social services and libraries in a capitalist society), the inner workings of the internet just passed me by. I don’t know when exactly building websites became synonymous with knowing a lot of JavaScript and understanding what, exactly, is meant by that mysterious phrase “back-end” that I had tossed around so casually—as in, “Oh, if you want this to be connected to a database, we’ll need someone to handle the ‘back-end’ bit.” I don’t know when it happened, but I knew that I was sick of mentally punting that responsibility to other people. I hated that there was an entire domain of technology that I was almost entirely ignorant of, and I hated to see it invading my precious internet and closing me off from playing around and understanding how things work.

I also hated putting up with sexist bar patrons and trying to fight my way through the male-dominated craft beer industry, which I had sort of fallen into after failing to find library work, or copywriting work, or editing work, or any other sort of gainful employment after relocating to London. So naturally, becoming a web developer seemed like a solid career move. If I had to put up with sexist pigs, at least I could get paid a bit more handsomely for it, and go back to working regular daytime hours.

The lessons I took away from GA are not necessarily the ones I thought I was paying for. The Web Development Immersive course teaches students how to read documentation—this is a very important skill for an aspiring developer. It teaches the basics of how to use Git + GitHub, and makes sure everyone is able to put together a CV and portfolio showcasing the projects built over the course of the program. The course assignments start out pretty interesting, as students learn the basics of programming and thinking logically to build simple games like tic-tac-toe or roshambo in JavaScript, and the curriculum builds students up to a level where they’re able to create standalone webapps that run locally using whatever framework is in vogue and being taught by the course—we learned to build boilerplate applications with Express, with Sinatra, with Rails; we learned the basics of jQuery syntax and a bit about SASS. I learned that the instructional team and advisors at General Assembly thought that my Twitter account was too aggressively feminist and that it would prevent me from finding jobs. I learned that if the white men who pay for the course think that there’s a pipeline problem in tech that it’s not my place to correct them, and that if there are fewer female developers it’s because women just aren’t as interested in computers. I learned that junior developers don’t write tests in their jobs; that task is reserved for senior developers. The point is, I learned a lot, and much of it was good and useful, and some of it was not. As I saw more examples of the type of developer I didn’t want to be, I was able to form a pretty decent impression of the type of developer I’d like to become.

I’ve always been comfortable enough hacking away at things to make them work—in my view, that’s not the mark of a professional. If I’m to make this my vocation, I want to do it well, like, really well. I want to be able to write software that other developers can look at and say, “Yes, this makes sense.” I want to write code that’s maintainable, performative, self-documenting, well-tested, that does what it’s meant to do. I also want to really, deeply understand the tools I use, which is a process I understand will take rather a lot of time.

It’s hard not to despair at times, feeling like I’m at least a decade behind the curve and missing so much foundational knowledge. It’s even harder to measure my progress—how can I quantify knowledge gained, or deeper understanding slowly percolating in my mind? I can’t throw together a Rails application any faster now than I could when I built one for one of my GA projects, but my process for doing so is completely different now (and it includes a hell of a lot more test writing).

My favourite part of being a professional developer so far is, surprisingly, something that’s a bit of a divisive topic: Code review. After years of hacking away at things and making them work, it’s so refreshing to have the confidence to share my code with a mentor and get feedback (even when the feedback is basically, “Tear it all down and start over, but here’s where to start and what to think about”). I’ve been really fortunate to work alongside great developers who give thoughtful, considered feedback and are exactly as pedantic as I’d like them to be. I’ve gotten great feedback about design decisions, architectural patterns, structuring database queries, and how to optimise for performance, and I’ve learned that naming things probably isn’t as hard as everyone thinks it is—at least, not if you’ve got a decade of writing and editing experience under your belt.

I’m extremely grateful for everyone who took a chance on me and helped me get this far over the past year—pretty sure you know who you are already, and naming names feels a bit gauche. I plan to repay that debt by putting in the effort to grow into a contributing member of the community, continually fighting against discrimination and cultural hegemony, helping to encourage aspiring developers to boldly pursue their dreams, and calling out bullshit and bad takes whenever I see them. In short, I’ll continue to just be myself, but I’ll probably get further and bring more people along with me thanks to your help and support.

xx, Kaitlyn

Switching to Netlify

2017-05-30T00:00:00+00:00

This site had been using GitHub Pages for hosting for the past N months. I use Heroku for most of my projects, so paying for a hosting service just for this simple static site felt like a waste of money. Plus, I wanted to give GitHub Pages a go and see how it all worked. It was fine, mostly, except for one massive, glaring issue: If you use a custom domain with GitHub Pages, it’s really not a simple matter to add an SSL certificate and force connection over HTTPS. This has been low-key irritating me for ages, but all of the solutions I’ve found require you to use Cloudflare as a CDN, and I’m trying to avoid relying too heavily on their services.

Anyway, wow, Netlify! It’s amazing. It took me less than five minutes to create an account, trigger a build from my master branch on GitHub and verify that everything worked well before moving my DNS over and adding an SSL certificate. I couldn’t be more impressed. The only final step was renaming my repo on GitHub to disable the link with GitHub Pages. Response times for loading the site have also been slashed by about 80%. If I’d known it would be this easy, I would have done this months ago. It’s so simple I’m tempted to build fun little sites for every random domain I have registered, just to see how fast and easy the setup is with Netlify. So far, I’m an extremely happy customer.