On being clear about your skillset

We’ve been hiring for a Design Engineer recently, and it’s made me think a lot about how we describe what we do. We’ve sifted through plenty of applications with that title where the experience shown is primarily design and prompting AI to build prototypes.

Being able to turn an idea into something you can interact with is useful, and I’d encourage designers to explore it. The thing is, when we’re hiring a Design Engineer, we also need to understand how much of the implementation that person can take responsibility for today.

For me, a Design Engineer needs to be able to work through a design problem and own its implementation in a real product. That includes understanding the code, investigating why something breaks, considering accessibility and performance, and making changes that other people can maintain. AI can help with all of that, but you still need enough understanding to judge its output and take responsibility for what ships.

I don’t particularly care how much code someone typed themselves. I care whether they can explain the decisions, recognise the problems and work through them. A convincing prototype is a useful piece of evidence, but it doesn’t tell me all of that on its own.

If you’re a designer learning to build with AI, you can say that. Tell me what you’ve made, which parts you understand and where you still need support. It gives me a much better place to start than trying to work backwards from the title alone.

The ambiguity makes hiring incredibly laborious. When the title suggests a fit that the work doesn’t support, candidates can get prioritised for conversations that won’t lead anywhere. Meanwhile, good applicants whose relevant experience is harder to find can get overlooked. We have a responsibility to read carefully, but unclear applications make it harder to give everyone the consideration they deserve.

Seniority is part of this too, and there’s an awkward wrinkle at DuckDuckGo: what we call Senior is what most companies would call Staff. I can see how that makes it harder to judge a role from the title alone. Our job specs always clarify the experience we expect candidates to bring, so you shouldn’t have to know our internal levels to understand what we’re looking for.

Our recent role is aimed at that Staff level of experience, yet we’ve had a lot of junior applicants. I understand wanting to stretch yourself, and you shouldn’t need to meet every bullet point before applying. But there’s a substantial gap between needing to learn a particular tool and needing support to do the core work of the role. At that level, I’m looking for the judgement to navigate ambiguity, guide decisions and help other people deliver, alongside the ability to build.

Read the full job spec and the application questions before you apply, then read your answers back against them. Make the relevant experience easy to find. If you’re making a career transition, explain where you are in it and why you think this particular role fits.

Hiring teams owe applicants the same care. We need to be explicit about the work and level we need, distinguish essentials from preferences, and read what people actually send us. A title means different things at different companies, so it can’t do all the explaining for either side.

Applying takes time and energy, often when both are already stretched. Reviewing and interviewing takes time too, and it’s frustrating to get several conversations in before realising we’ve been talking about different jobs. A bit more clarity at the start would help us all.

If you’re figuring out your next step, moving into Design Engineering or looking for some mentoring, I’d be happy to chat. We can talk through your experience, where you’d like to go and what might help you get there. Book some time below.