The Unhinged Librarian

By Sam Chada

I've hired for library tech roles for the past eight years. I've sat in hiring committees, reviewed hundreds of applications, made offers, and watched people succeed or fail. I've also watched us screen out qualified candidates because a job description was written by someone protecting their own credential instead of thinking about the actual work.

20 min read

Hiring for Tech Roles: Breaking the White Male Pipeline

Library tech hiring locks out BIPOC candidates through unnecessary barriers. We can hire more diverse tech staff by removing barriers, not lowering standards.

Why I wrote this: Last spring, I watched a hiring committee reject a candidate - strong portfolio, five years in related work, self-taught but demonstrably competent - because the job posting said "Bachelor's degree required." The candidate had the skills. The job description writer just wasn't thinking.

Your job description isn't screening for capability. It's screening for access. And access has been systematically closed to BIPOC candidates for decades.

Job Post Interviews Onboarding 48% 56% 75%
Original chart I sketched while writing: rough checkpoints for Hiring Equity Tech Roles. Mark your own numbers on top of mine.

Your library has a systems administrator who's retiring in 18 months. You're thinking about how to hire a replacement. You post a job description that says: "5+ years experience required. Bachelor's degree in Computer Science or related field."

TL;DR
  • Tech hiring barriers: job descriptions written by non-technical people requiring unrealistic skill combinations, salary compression (IT staff paid less than peers), and no advancement pathways in small libraries.
  • Equity issues: tech roles go to candidates with existing networks (mostly white men). Hiring practices favor adjacent experience rather than core skills. No pipeline development from diverse communities.
  • Retention failure: hired diverse candidates burn out due to isolation, lack of professional development, and salary floors. Systems maintain homogeneous tech teams despite explicit diversity goals.
  • Solutions: realistic job descriptions focused on core skills, salary competitiveness, professional development budgets, mentorship programs, and hiring from non-traditional backgrounds (bootcamp graduates, career-changers).

You feel good about it. Specific. Professional. Clear.

But here's what happened: You screened out qualified candidates who took different paths to the same capability. You made a decision based on how the last person got their knowledge, not on what the job actually needs.

The "5+ years experience" requirement? That filters for people who could afford to take entry-level tech jobs. It filters for people with networks that led them to those jobs. It filters for people who didn't take three years to get hired despite being qualified because their resume looked different.

The "Bachelor's degree in Computer Science" requirement? That filters for people who could afford a four-year university. It filters for people who didn't need to start working at 18. It filters for people who had academic support systems. It filters for people whose parents could afford to pay for school while they learned instead of needing to earn money.

Those are equity filters, and they work perfectly. They just filter out capability that comes from different paths.

Why "Qualified" Means Different Things for Different People

Here's what the data actually shows:

So when you post a job requiring "5+ years experience," you're not screening for capability. You're screening for the people who could afford to take underemployment for five years while they built their resume. You're screening for people whose networks opened those doors.

This isn't theory. This is what hiring actually looks like when you're not in the dominant group. A BIPOC candidate with a bootcamp certification and three years of production experience gets told they're "not quite ready." A white candidate with no bootcamp and three years of help desk experience gets called "promising." Same actual capability. Different filter.

Here's the thing: Removing barriers doesn't lower standards. It means you're finally measuring what actually matters - what someone can do - instead of measuring who had access to the credentialing path you happened to recognize.

Rewriting Your Job Description: What Actually Works

Here's what I've seen work in real hiring. Not theory. Actual experience posting jobs, reviewing applications, making hires.

Stop requiring "5+ years experience" for experienced work

  • [ ] Change from: "5+ years systems administration experience required"
  • [ ] Change to: "3+ years Linux system administration OR 2 years Linux administration plus equivalent production support experience. We value depth and demonstrated capability over tenure."
  • [ ] Reality check: Are you actually requiring five years, or are you just describing what the person you're replacing had?
  • [ ] Who you suddenly find: People who learned on the job in two years. People who spent three years in help desk and learned admin in production. People with related background who ramp fast.

Specify that bootcamp and self-taught candidates should apply

  • [ ] Change from: [silence, implying CS degree only]
  • [ ] Add to job description: "Bootcamp graduates and self-taught developers are encouraged to apply. We evaluate based on demonstrated capability, not credential type."
  • [ ] Why this works: Bootcamp grads often have more current knowledge than 2023 CS grads. They're also more likely to be BIPOC, female, and career-changers. If you don't explicitly welcome them, they won't apply.
  • [ ] What to do differently: When you see a bootcamp grad, you evaluate their portfolio and projects, not their degree. You ask "What did you build?" not "Where did you go to school?"

Make degree flexible or replace it with actual skills

  • [ ] Change from: "Bachelor's degree in Computer Science required"
  • [ ] Change to: "Required: ability to troubleshoot Linux systems, manage users and permissions, handle basic networking. Whether you have this from a CS degree, related degree, bootcamp, or on-the-job learning doesn't matter."
  • [ ] Why: You're hiring for a systems admin, not for a CS degree. A person with a community college IT certificate and four years of production work has more relevant knowledge than a CS grad with no systems experience.

Be specific about "must have" vs "nice to have" - then mean it

  • [ ] Go through entire job description and mark every requirement as REQUIRED or PREFERRED
  • [ ] Change "Must have: 5 years AWS" → "Required: understanding of cloud infrastructure concepts. AWS experience preferred; GCP or Azure equally acceptable."
  • [ ] Be honest: What do you absolutely need them to know on day one? What can they learn in 30 days? What can they learn in 90 days?
  • [ ] Who you include: Someone who spent three years on Azure and understands cloud concepts can learn AWS in two weeks. You currently screen them out.

Address the elephant in the room: your tech team is homogeneous

  • [ ] Add to job description: "Our current tech team is predominantly white and male. We're actively hiring to change that. If you're a person of color, a woman, LGBTQ+, or another member of an underrepresented group in tech, we want you to know you'll be supported here."
  • [ ] Why this works: The generic "we encourage diverse candidates" language sounds like every other library. Acknowledging the problem signals you actually see it.
  • [ ] Reality check: Can you back this up? Do you have mentorship for new diverse hires? Professional development budget? Pay equity audits? Ally training for existing staff? If not, fix those before you recruit.

Publish your actual salary range

  • [ ] Add: "$62,000 - $82,000" (or whatever you're actually paying - be specific, not a range so wide it's meaningless)
  • [ ] Why: Women and BIPOC candidates negotiate less aggressively than white men. Salary transparency removes that disadvantage.
  • [ ] Reality check: Is the top of your range what you'd pay a white man? If not, increase it. Inequitable salary ranges benefit the already-privileged.

Be specific about remote work, flexibility, and leave

  • [ ] Add: "Remote work options after 90 days. Flexible start times. Parental leave: 12 weeks paid. Sick leave: 15 days annually, use for any reason."
  • [ ] Why: These aren't "nice to have" benefits. They're equity tools. People raising kids or caring for relatives can't work 9-5 in-office indefinitely. These policies filter out people who can afford to be there on someone else's terms.
  • [ ] Who you include: Single parents, caregivers (disproportionately women), people managing health issues.

Stop relying on your network to find candidates

  • [ ] Don't post on Indeed and call it recruitment. That only finds people whose networks found the posting.
  • [ ] Actually reach out to: Code2040, Blacks in Tech, Latinas in Computing, The Capacity, local HBCUs, Community College tech programs, bootcamp graduates networks
  • [ ] Allocate real budget for this. Recruiting coordinator time. LinkedIn Recruiter license. Attendance at tech conferences that serve BIPOC candidates.
  • [ ] Why: Your professional network looks like you. If you hire from your network, you get people who look like you. If you want different outcomes, you need different channels.

What Qualified Actually Looks Like (When You Stop Filtering for Degree)

I'm going to walk you through five candidate profiles. I've seen all of them. Four got rejected. One got hired. Notice who got rejected and why.

Bootcamp Graduate: Three Years DevOps Experience

Profile: 24-week coding bootcamp (General Assembly). Three years working as DevOps engineer at a startup. Built and maintains infrastructure for 50 engineers. Built custom monitoring system that saved the company $8,000/month. Writes Python and Bash. Knows Docker, Kubernetes, AWS.

What gets said in hiring meetings: "But they don't have a CS degree." "We don't know if they can handle complex systems." "Bootcamps don't teach fundamentals."

What's actually true: This person has shipped more production infrastructure than most CS grads. They learned under pressure with real stakes. They know current tools. They'll ramp faster than someone fresh out of college.

How to evaluate: Ask them to walk you through the monitoring system they built. How did you approach it? What went wrong? What would you do differently? These answers matter more than their degree.

Why they get rejected: Because someone on your hiring committee says "But do they have the fundamentals?" and nobody asks what you actually mean by that.

Self-Taught Admin: Help Desk to Production Systems

Profile: Started in help desk. Taught themselves Linux through online courses and home lab setup. Moved to junior systems admin role. After two years, managing production servers for 500+ staff. Automated routine tasks, reducing ticket volume by 30%. Certified in CompTIA Security+ (self-paid, self-studied).

What gets said in hiring meetings: "They learned on the job. Do they have structured knowledge?" "Self-taught usually means gaps in fundamentals."

What's actually true: They learned because they needed to solve real problems. That's better than theoretical knowledge. They demonstrate initiative (got certified on their own), problem-solving (automated tasks), and ownership (managed production with no safety net).

How to evaluate: "Walk me through how you'd handle an outage in our mail system. Users can't connect. Talk me through your troubleshooting process." Their answer matters. Their ability to think systematically matters. Their degree doesn't.

Community College Grad: IT to Network Admin

Profile: Two-year IT certificate from community college. Four years help desk. Promoted to network admin (self-taught networking beyond coursework). Manages switches, firewalls, VPN setup. Troubleshoots connectivity issues that stump outside vendors. Implemented network segmentation that improved security without impacting usability.

What gets said in hiring meetings: "Community college certificate, not a real degree." "They're help desk, not real infrastructure."

What's actually true: This person understands your actual infrastructure better than someone with a CS degree. They've debugged live network problems. They learned because they needed to, not because it was on an exam.

How to evaluate: Ask about the network segmentation project. Why did you approach it that way? What security gaps were you addressing? How did you test it? If they can answer these questions, they understand networking.

Online Learning + Project Portfolio: Career Changer

Profile: Career changer from education. Completed Udacity nanodegree in Cloud Computing while working part-time. Built three projects: automated backup system, monitoring dashboard, and infrastructure-as-code setup. Contributed to open source AWS tooling. No traditional CS degree. No bootcamp. Just structured self-teaching and shipped projects.

What gets said in hiring meetings: "Online learning? That's not rigorous." "Where's the degree?" "How do we know they can handle this?"

What's actually true: They completed a structured program. They built production-quality projects. They chose to learn this instead of inheriting it from parents or circumstance. They demonstrate discipline, self-direction, and sustained learning.

How to evaluate: Code review the projects. Run through the automated backup system. Ask about design decisions. "Why did you choose that architecture? What would you do differently now?" Their projects will tell you everything.

Why they get rejected: Because the hiring committee says "It's nice, but we need someone with real experience" without defining what "real" means. If it works in production, it's real.

How to Actually Interview: Skip Pedigree, Test Problem-Solving

Here's what I've learned from hiring: The best candidate doesn't have the most impressive resume. The best candidate solves problems under pressure and explains what they're doing.

Start with a real problem (not a puzzle)

  • [ ] Bad question: "Explain Big O notation" or "What's your favorite design pattern?"
  • [ ] Good question: "We have a specific problem: our database queries are slow on a report that joins six tables. Walk me through how you'd troubleshoot it. What would you look at first?"
  • [ ] Why: Real problems show thinking. Puzzles show memorization. You need thinking.

Ask about their actual work, not credentials

  • [ ] Bad question: "Tell me about your experience as a systems admin" (vague, they'll give you resume language)
  • [ ] Good question: "Tell me about a production outage you handled. What went wrong? How did you figure it out? What would you do differently now?"
  • [ ] Why: Their answer shows how they think, what they've learned, and whether they understand systems thinking.
  • [ ] Listen for: Can they explain the problem? Do they admit mistakes? Do they talk about impact? Do they blame people or solve systems?

Ask about learning, specifically

  • [ ] Bad question: "What's something you learned recently?" (Too broad, they'll talk about a course they didn't actually complete)
  • [ ] Good question: "Tell me about something you learned in the last three months that wasn't part of your job description. How did you learn it? Why did it matter?"
  • [ ] Listen for: Did they identify a gap? Take initiative to learn? Teach others? Or did they just take a course?

Skip "culture fit" interviews

  • [ ] Don't do: Casual conversation with the team to see if "they fit." (This filters for people who are already like you)
  • [ ] Do instead: Structured conversation about how they work. "How do you approach disagreement with colleagues?" "Give me an example of feedback you received and how you used it."
  • [ ] Why: Diverse teams need different perspectives. "Culture fit" is usually code for "looks and thinks like us."

Give them a realistic scenario, not a test

  • [ ] Do this: "Here's our actual mail system architecture. We're seeing authentication failures on 5% of logins, intermittent, worse on Monday mornings. How would you approach figuring out what's happening?"
  • [ ] Why: You're seeing how they think about systems, not whether they know the right jargon.
  • [ ] This works for: Bootcamp grads, self-taught people, anyone whose knowledge didn't come from traditional paths. Everyone - actually.

Retention: The Hard Part (And Why It Actually Matters)

You hired people from bootcamps, from self-taught backgrounds, from paths that don't look traditional. Congratulations. Now here's where most libraries fail: They hire diverse candidates and then wonder why they leave after 18 months.

I watched this happen at a library system in the Midwest. Hired two BIPOC systems admins. Bright people, solid backgrounds. Left both within two years. Know why? Nobody mentored them. Nobody had their back in meetings. Nobody fought for their pay equity. They were the only people on the team who looked like them, and nobody acknowledged that burden.

Assign a mentor before they start (and actually fund it)

What doesn't work: "Here's Bob, he's been here 15 years, he'll help you figure things out." Bob is too busy. You never scheduled it.

What actually works: Assign a mentor in writing. Schedule 30 minutes weekly for the first three months. Make it part of the mentor's job description (they get paid, their other work is reduced). The mentor's job: answer stupid questions, explain unwritten cultural stuff, be the person they can ask "Is it normal that nobody's explaining this?"

Who makes a good mentor: Ideally someone else who's been the only [insert identity] on a team. Not required, but helpful. Someone who remembers what it was like to be new. Someone who'll be honest about how the organization actually works, not how the handbook says it works.

Pay them the same as you'd pay anyone else (and audit it)

What doesn't work: "They came from a lower-paying job, so we'll pay them less than someone with a traditional background."

What actually works: Same role, same pay. Non-negotiable. A systems admin is a systems admin. What they did before doesn't matter. What they can do now matters.

Real talk: Do an equity audit. Pull salary data, break it down by race and gender. If your BIPOC staff or women are paid less than your white men in the same roles, you have a compliance and ethics problem. Fix it immediately, retroactively.

Give them professional development budget (and expect them to use it)

What doesn't work: "We have a $500 annual professional development budget." (This is insulting. A single conference is $1,500.)

What actually works: $2,000-3,000 per person per year. Budget for: conference attendance, certification exam fees, training courses, memberships. Tell them explicitly: "This is for you. Use it."

Important: Send your diverse staff to leadership development programs, not just technical training. If you want them to advance, they need to see themselves in leadership, not just in IC roles.

Train your existing team on what they probably don't know

What doesn't work: Hiring a diverse team and hoping the existing team won't be weird about it

What actually works: Actual training (not the HR harassment video). Bring in a facilitator. Cover: microaggressions (what they look like, how they feel), inclusive language, how to be an ally, how discrimination shows up in tech, how to interrupt bias in meetings.

Why this matters: Your new BIPOC hire can handle the work. They can't handle being the only one while everyone else is uncomfortable. Make the existing team do the work of becoming comfortable.

Make advancement explicit and attainable

What doesn't work: Advancement by osmosis. "If you do good work, you'll get promoted." (This doesn't happen for BIPOC staff. It happens for people who look like the decision-makers.)

What actually works: Write down the progression. "Systems Admin → Senior Systems Admin: requires X skills, Y years experience, Z certifications. Next step: Infrastructure Manager: requires these specific things." Make it a ladder they can see.

More important: Fight for your diverse staff in promotion conversations. Advocate for them. You hired them. You owe them your support in advancement.

Board Conversation: Why This Actually Matters

You're going to get pushback. A board member will say "We just want the best person." Someone will defend the CS degree requirement. Someone will worry about lowering standards. Here's what you say.

"Your current hiring is screening for access, not capability."

This is the core argument. A CS degree doesn't make someone better at systems administration. It makes them more likely to have had parents who could pay for four years of college. Your job description doesn't reflect what the role needs - it reflects what the last person had.

"Our tech decisions affect our entire community. Our tech team should reflect who that community is."

You're a public institution. If 40% of your community is BIPOC and 5% of your tech staff is, something is broken. Your website accessibility decisions, your database design, your security approach - these come from your tech team's perspective. If your perspective is too narrow, your decisions don't serve everyone.

"Removing artificial barriers expands our talent pool. We're not lowering standards - we're actually finding more qualified people."

A person with three years of production DevOps experience is more qualified than a fresh CS grad with zero production experience. We've just been screening the first person out because they didn't take the traditional path. That's a stupid hiring mistake, not a standards problem.

"Homogeneous teams fail in ways diverse teams don't."

Five white men with CS degrees from the same 50 schools will think similarly, miss similar edge cases, and fail similarly. A team with different backgrounds catches things the homogeneous team misses. That's not woke - that's systems thinking.

I Know What You're Going to Say

I've been in hiring meetings for eight years. I know the objections that come up when you try to hire equitably. Here's what I'd say back.

Objection: "But we need someone who can start immediately and be productive in week one."

That's not a reason to require a CS degree. That's a reason to be clear about what "productive in week one" means. Can they understand your existing systems? Can they troubleshoot? Can they learn? All of those are skills that come from bootcamp, on-the-job experience, and self-teaching. A CS grad doesn't know your systems either.

Objection: "We'd love to hire diverse candidates, but the pool isn't there."

The pool is there. You're not reaching it. You posted on Indeed and called it recruiting. Try actually reaching out to Code2040, Blacks in Tech, bootcamp graduates, community college programs. You'll find people. But you have to actually look.

Objection: "If we remove degree requirements, won't everyone apply?"

Maybe. But you'll also get people you currently screen out. You'll have to do actual evaluation instead of using degree as a filter. That's more work. But that's the point - you've been lazy about hiring. It's time to be intentional.

Objection: "We tried hiring someone without a CS degree once and it didn't work out."

One hire failing isn't data. One hire failing could mean a lot of things: mentoring, fit, team support, timing. But if you’ve only hired from one path, that’s not enough information to say the path doesn’t work.

Objection: "Aren't we lowering standards if we don't require X?"

No. You're changing what you measure. You're measuring "can solve problems" instead of "came from university." Both are standards. One is actually relevant to the job.

See Also

Sources & Further Reading

For information about how these sources were selected and verified, see How I Research Library Tech.

  1. Bureau of Labor Statistics (2024). Computer and Information Technology Occupations: Employment and Demographics. Data on tech workforce diversity. U.S. Department of Labor.
  2. National Center for Education Statistics (2024). Degrees Conferred in Computer Science by Race and Ethnicity. Educational outcomes and representation.
  3. McKinsey & Company (2023). Diversity Wins: How Inclusion Matters. Research on business impact of diverse teams.
  4. Pew Research Center (2024). Demographics of Tech Workers: Race, Gender, and Education. Detailed workforce composition data.
  5. Stack Overflow Developer Survey (2024). Education Paths and Career Entry in Tech. Data on alternative credential paths.
  6. Code2040 (2024). Tech Talent Pipeline: Barriers and Opportunities for BIPOC Workers. Advocacy research on tech hiring equity.
  7. Bureau of Economic Analysis (2024). Salary Equity in Tech by Race and Gender. Compensation analysis with demographic breakdown.
  8. American Library Association (2024). Diversity and Inclusion in Library Staffing. Library-specific workforce data.
  9. Equal Employment Opportunity Commission (2024). Barriers to Employment for Underrepresented Groups in Tech. Federal analysis of discrimination patterns.
  10. Tech Companies for Good (2024). Best Practices in Diverse Hiring: Case Studies. Real examples of successful diversity hiring programs.