<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Hiring on guy@secdev.uk</title>
    <link>https://www.secdev.uk/blog/tags/hiring/</link>
    <description>Recent content in Hiring on guy@secdev.uk</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <copyright>Guy Dixon | guy@secdev.uk</copyright>
    <lastBuildDate>Mon, 30 Mar 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.secdev.uk/blog/tags/hiring/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>The New Shape of the Engineering Team</title>
      <link>https://www.secdev.uk/blog/leadership/4.3-the-new-shape-of-the-engineering-team/</link>
      <pubDate>Mon, 30 Mar 2026 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/leadership/4.3-the-new-shape-of-the-engineering-team/</guid>
      <description>&lt;p&gt;If AI can handle the boilerplate, the scaffolding, and a growing portion of routine implementation, what does that mean for how we compose engineering teams? It&amp;rsquo;s a question I&amp;rsquo;ve been turning over for a while now, and the answers I keep arriving at are uncomfortable.&lt;/p&gt;&#xA;&lt;p&gt;The optimistic version is that AI frees engineers to focus on higher-value work, system design, problem framing, user understanding, architectural thinking. The pessimistic version is that it eliminates the entry-level work that junior engineers have traditionally used to learn the craft. The realistic version is probably somewhere in between, and navigating it well is one of the most important challenges facing technical leaders right now.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Hiring for Values, Abilities, Then Skills</title>
      <link>https://www.secdev.uk/blog/leadership/3.2-hiring-for-values-abilities-then-skills/</link>
      <pubDate>Mon, 08 Sep 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/leadership/3.2-hiring-for-values-abilities-then-skills/</guid>
      <description>&lt;p&gt;Most engineering interviews are backwards. We spend the majority of our time evaluating technical skills, the thing that&amp;rsquo;s easiest to teach and quickest to develop, and almost no time evaluating values and abilities, which are much harder to change and far more predictive of long-term success.&lt;/p&gt;&#xA;&lt;p&gt;I&amp;rsquo;ve made this mistake myself, repeatedly. I&amp;rsquo;ve hired brilliant engineers who turned out to be terrible collaborators. I&amp;rsquo;ve passed on candidates who weren&amp;rsquo;t the strongest technically but would have been exactly what the team needed. The more I&amp;rsquo;ve hired across start-ups and corporates, the more convinced I&amp;rsquo;ve become that we need to flip the order.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Building Diverse Teams That Actually Work</title>
      <link>https://www.secdev.uk/blog/leadership/1.9-building-diverse-teams-that-actually-work/</link>
      <pubDate>Mon, 09 Dec 2024 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/leadership/1.9-building-diverse-teams-that-actually-work/</guid>
      <description>&lt;p&gt;This is one of those topics where I&amp;rsquo;ve watched the conversation evolve significantly over the course of my career. Twenty-five years ago, &amp;ldquo;diversity&amp;rdquo; in tech largely meant making sure the team photo didn&amp;rsquo;t look &lt;em&gt;entirely&lt;/em&gt; homogeneous. The bar was low, and most of us, myself included, didn&amp;rsquo;t think critically enough about what we were missing. The more I&amp;rsquo;ve researched this topic and reflected on my own experience leading teams of different shapes and sizes, the more I&amp;rsquo;ve come to believe that diversity isn&amp;rsquo;t just the right thing to do. It&amp;rsquo;s the thing that makes teams actually work better. But only if you pair it with genuine inclusion. Without that, it&amp;rsquo;s just optics.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
