From university to delivery: What our summer interns learned by solving a real public sector problem

Seyed Razavi-Nematollahi

We reflect on Zaizi’s summer internship and what both our interns and mentors learned along the way.

What happens when you give a group of university students a public sector problem, eight weeks, access to an experienced digital team and enough freedom to work out the rest for themselves? 

There is a big difference between learning how something should be done and having to make it work in the real world.

That transition from theory to delivery was exactly what we wanted the internship to explore.

As one of the interns put it, university teaches you what to consider when solving a problem. In a real delivery environment, you quickly discover another dimension: “we’ve got client constraints and we’ve got time constraints”.

Rather than giving our interns a tightly prescribed technical exercise, we wanted them to experience more of what delivering digital services is actually like: understanding a problem, talking to users, making decisions as a multidisciplinary team, managing scope and, ultimately, building something useful.

Eight weeks later, what stood out wasn’t simply the prototype they had built. It was how much ownership they took to get there.

Starting with a problem, not a specification

We deliberately gave this year’s interns a lot of freedom.

Their initial brief was broadly to identify and explore a public sector problem. They had to generate ideas, decide where they could make an impact and work out what was achievable within the time available.

That ambiguity was intentional, although not  always comfortable.

The interns described initially struggling to understand what sort of project they should pursue. A guided ideation session helped them narrow their thinking but the final decision remained theirs.

“The level of independence that we had… makes you learn a lot more because you’re stuck in there and you kind of have to do it yourself,”

said one of the interns. 

Choosing something the team genuinely cared about kept them motivated to see it through, rather than feeling like they were completing another piece of university coursework.

And once they settled on their direction, the change was noticeable.

Our mentors saw the team move quickly from uncertainty into confidently planning their own work, running stand-ups and retrospectives, assigning responsibilities and seeking out the people and information they needed. The mentors were there when required but increasingly, they didn’t need to be.

Learning to build the right thing

One of the strongest themes to emerge from the internship was something that wasn’t primarily about technology at all. It was the importance of user research.

The interns didn’t simply sit at their laptops and assume what people needed. They went out and spoke to users.

“It’s never something I’d considered before,” said one of the interns. The team discovered how research could directly influence technical decisions: shaping the scope, identifying useful features and, just as importantly, deciding what they didn’t need to build.

That proactive approach impressed us. Rather than waiting for research participants to come to them, the interns found other ways to get the insight they needed.

It’s an important lesson for any digital team, not just interns: don’t allow the process to become the blocker. Find ways to learn from users and allow the evidence to shape what you build.

Scope is a technical skill too

Once you understand the problem, another challenge emerges. Deciding how much of it you can realistically solve.

The team had plenty of ideas. The difficult part was deciding which ones mattered most.

“There’s a lot of, ‘oh, this would be nice to do’,” an intern explained, “but realising that actually you’ve got other things that need to take priority.”

It is a familiar problem in government delivery. Time and budgets are finite, while ambitions rarely are.

The interns had to learn that building a good service doesn’t mean building every possible feature. It means understanding what creates the most value, making conscious trade-offs and leaving some good ideas for later.

In other words, they encountered scope creep and learned why prioritisation is an important part of professional digital delivery.

From not knowing where to start to building a complete system

The technical development across eight weeks was equally striking.

The interns arrived with different degrees and very different levels of development experience. That was a feature rather than a problem.

For one intern, much of the coding experience was new. Before the internship, he said that looking at the components involved in building an application would have left him unsure where to begin.

By the end, that had changed. “I’d know where to start. I’d know the processes,” he reflected.

Another had previously worked with frontend and backend development but never connected those pieces into a complete system. The internship allowed her to understand the wider development lifecycle and how the components of a working service fit together. 

The interns took ownership of a rules engine and experienced another very real engineering milestone. Building a component independently and then successfully integrating it with somebody else’s work.

And sometimes the most memorable moments were much simpler, like making changes and then opening the browser to physically see what they’d built. “It put a very big smile on my face,” said one intern. 

Anyone who builds software will recognise the feeling.

Giving people responsibility with support around them

The internship was intentionally structured to give them the skills needed to solve problems in digital delivery.

The first week included workshops designed to establish a common baseline across areas where the interns had very different levels of experience. Mentors and the wider Zaizi team were available throughout and the interns had opportunities to present their work and receive feedback.

But the important part was knowing when to step away. Our product manager Beth expected mentoring to be much more hands-on. Instead, she found the team “got stuck in and reached out to the right people without having to be handheld”.

The interns independently ran their delivery ceremonies and adapted them as they learned. They were encouraged to bring their own ideas rather than simply imitate how experienced colleagues worked. In one retrospective, one intern introduced an approach that delivery manager Trusha liked enough to say she planned to use herself on future projects.

Learning, it turned out, wasn’t only travelling in one direction.

What did we learn from the interns?

Mentoring creates an interesting opportunity to revisit habits that become almost automatic once you’ve been working for a while.

Several mentors highlighted one deceptively simple example: asking questions.

The interns were comfortable saying when they didn’t understand something and reached out when they were stuck. For experienced colleagues, watching that behaviour was a useful reminder that spending hours struggling with a problem isn’t necessarily a sign of independence. Sometimes the best thing you can do is ask somebody.

Explaining established practices also forced mentors to think again about why we work in certain ways. Going back through agile principles, delivery processes and ways of working highlighted the difference between the textbook version and how practices naturally evolve on real projects.

As Beth put it, when you’re immersed in a project “you kind of just know stuff”. Having to explain it to somebody else makes you stop and think about why you do it.

That makes internships valuable beyond the people doing them. New perspectives challenge established teams to explain their assumptions, revisit good practices and occasionally learn a better way of doing something themselves.

Confidence comes from doing

Perhaps the biggest change over the eight weeks wasn’t something we could measure in code. It was confidence.

We deliberately gave the interns opportunities to communicate what they were doing as well as build it. They presented at our Club Connect session, ran through dry runs together, challenged each other’s story and later delivered a formal midpoint review.

By then, the difference was dramatic. The midpoint review had a clear narrative, professional slides and every member of the team confidently explaining what they had achieved and where they were going next. It wouldn’t have looked out of place in one of our client delivery teams.

That progression reinforced something worth remembering when developing early-career talent. Confidence doesn’t necessarily come from making the challenge easier. It can come from giving people meaningful responsibility, allowing them to work through uncertainty and providing a safe environment in which they can ask for help.

Advice for future interns

One of the strengths of this year’s group was their willingness to move outside their existing experience, learn from each other and ask questions.

One of the interns encouraged us to continue giving opportunities to people who may not already have a coding background but have the curiosity and desire to learn.

That feels like a fitting summary of the internship as a whole. 

Eight weeks isn’t enough time to learn everything about delivering digital services and that’s not the objective.

But it is enough time to discover that user needs matter more than your assumptions. That good teams make trade-offs. That software is built collaboratively. That asking for help is a strength. And that the best way to develop confidence is often to be trusted with something real.

What advice would the interns give somebody thinking of applying next year?

“Be curious.”

You don’t need to know everything on day one. You just need to be prepared to learn.

Thanks for joining us! We’ll keep you informed with regular updates.

[gravityform id=”16″ title=”true” ajax=”true”]