Hiring Developers in NZ

The NZ developer market in 2017 is competitive in a way it wasn't five years ago. Tech sector growth has pushed demand up. Auckland and Wellington are the main centres, but the available talent doesn't match the number of open roles. Seek and Trade Me Jobs are full of developer positions. Many of them stay listed for months.

The dynamics are straightforward. Good developers have options. They can work for large corporates, join startups, freelance, or move to Australia for a pay rise. Competing for talent against organisations with bigger budgets and more famous names isn't something a small studio wins on salary alone.

That number covers a wide range of experience and capability. Junior developers out of university or bootcamps. Intermediate developers with a few years of production experience. Senior developers who can architect systems and mentor others. The distribution is a pyramid, and the top of the pyramid is very narrow.

Six years of hiring for IDESIGN has given us a clearer picture of what works. Three lessons stand out.

We can't match the salary a developer would earn at a bank or a large consultancy. We don't try. What we offer instead is the work itself. Enterprise web applications built from scratch. Real problems with real constraints. The opportunity to work across the full stack rather than being assigned to one layer. Ownership of technical decisions rather than implementing someone else's architecture.

That attracts a specific kind of developer. Not the one optimising for compensation, which is entirely valid, but the one optimising for craft and variety. Those developers tend to be the ones who get better fastest, because they're motivated by the work, not just the paycheck.

In a small team, a developer who can only write React components or only build APIs is a bottleneck. We need people who can work across the stack: frontend, backend, database, and enough infrastructure knowledge to deploy what they've built.

That doesn't mean we need experts in everything. It means we need people who are comfortable moving between layers, who can read unfamiliar code and figure it out, and who don't say "that's not my area" when a task crosses a boundary.

The NZ market actually produces these generalists naturally. Smaller teams mean fewer opportunities to specialise. A developer at a five-person firm in Auckland has done more types of work in two years than a developer at a large enterprise has done in five. That breadth is valuable.

I know "culture fit" has become a problematic phrase, and rightly so when it's used to exclude people who don't look or sound like the existing team. That's not what I mean.

What I mean is that IDESIGN's working style is specific. Design and engineering work together from day one. Developers sit in client meetings. Everyone is expected to understand the business problem, not just the technical task. We give feedback directly and receive it without defensiveness. The pace is fast but the quality standard is high.

Not everyone thrives in that environment. Some developers prefer clear specifications handed to them, headphones on, code written, ticket closed. That's a valid way to work. It's not how we work. Hiring someone whose preferred working style conflicts with ours is unfair to them and disruptive to the team.

We've made this mistake. We hired a technically strong developer who preferred to work in isolation, receive detailed specs, and minimise client interaction. They were talented. They were miserable. They left after four months. The technical ability was there. The fit wasn't.

The NZ developer market isn't large enough to rely on job postings alone. Most of our hires have come through three channels.

Network referrals. Our team knows other developers. When we're hiring, we ask. The best hires have come through personal recommendations from people we trust. The recommendation carries weight because the person making it understands how we work.

Community presence. Auckland's tech community is small but active. Meetups, conferences, online communities. Being visible in those spaces means people know who we are before we're hiring. When a role opens, it's not cold outreach. It's a warm conversation with someone who already has a sense of what IDESIGN does.

University connections. Our relationships with the University of Auckland's computer science and information systems departments have been valuable. We've hired junior developers who showed promise during their studies and invested in their growth. The hit rate on university hires is lower than on experienced hires, but the ceiling is higher. The best junior developers we've brought in have become integral to the team within eighteen months.

Our hiring criteria have evolved, but the core hasn't changed.

Technical foundation. Can you write clean, readable code? Do you understand data structures, algorithms, and web fundamentals? Can you debug a problem methodically rather than randomly changing things? This is the baseline. We assess it through practical exercises, not whiteboard algorithms.

Learning speed. Technology changes. The specific frameworks we use today won't be the ones we use in five years. What matters more than current knowledge is the ability to learn new things quickly and apply them in production. We ask candidates about the last thing they learned on their own and how they applied it.

Communication. Developers at IDESIGN talk to clients. They explain technical decisions to non-technical people. They participate in design discussions. If a developer can't articulate their thinking clearly, they'll struggle in our environment regardless of their technical ability.

Craft orientation. Do you care about the quality of what you build? Not perfection. Not gold-plating. But the basic standard of writing code you'd be comfortable maintaining in a year, naming things clearly, and leaving the codebase better than you found it. Craft shows up in the small decisions that nobody audits.

Hiring in NZ is hard. It takes longer than we'd like. We've had roles open for months. We've made offers that were declined because someone else offered more money or a more convenient commute. We've hired people who didn't work out.

The temptation is to lower the bar when the pipeline is thin. We've resisted that. A mediocre hire is more expensive than an empty seat. The team absorbs the management overhead, the code review burden, and the morale impact. Waiting for the right person costs less than hiring the wrong one and unwinding it three months later.

The NZ developer market is competitive, small, and imperfect. But the people we've found are exceptional. Building a team here takes patience, clarity about what you're looking for, and the honesty to admit when a hire didn't work out. We're still learning. But the team we have today is proof that you can build something strong from this market if you care about the people as much as the work.