What technical interns built at UNICEF

A clearer route through open-source guidance

Ida Delphine, then studying computer engineering in Cameroon, worked on the front end of UNICEF's Open Source Inventory. Her improvements included navigation and team-profile pages. She also described learning the site's publishing software through documentation and help from its community.¹

The Inventory had a practical audience. UNICEF's Venture Fund described it as a self-service resource on legal, governance and technology-policy questions, developed with start-ups and open-source practitioners.² Better navigation in that context helps a reader find guidance they may need for their own project.

For a prospective intern, the useful detail is the connection between the task and its user. Improving a menu may sound smaller than creating a new application, yet its value depends on what people need to find. Ask a team which problem a proposed project is meant to solve before judging it by its size.

Showing where digital projects were developed and used

Edil Baiyzbekov's portfolio identifies his UNICEF digital-public-goods map as a 2021 project. It brought together where open-source solutions were developed, where they were deployed and which Sustainable Development Goals they addressed. He describes a dashboard designed for interaction and editing.³

Those categories tell different stories. A project's place of development does not necessarily show where it is being used. Putting both on a map lets a reader explore that distinction instead of treating every marker as the same kind of information.

The project is therefore relevant beyond software development. It involves choosing what a reader should be able to compare, then building an interface that makes the comparison possible. For students interested in data work, a useful portfolio explanation would describe those decisions alongside the tools used.

Helping people understand whether they could apply

Rachita Saha described building an eligibility form for proposed digital public goods. Her account explains that she created an initial version, asked the communications team to test it and revised the content and workflow in response.¹

The Digital Public Goods Alliance's eligibility page still serves the broad purpose of helping people assess whether a solution can be nominated.⁴ The current page does not establish whether Saha’s original code remains in use. It helps explain the problem her project addressed: a visitor needs an understandable route to the appropriate next step.

Here, writing and testing the questions belong to the technical task. A working form can still confuse people if they do not understand what is being asked. Feedback from colleagues with a different specialism can expose problems a developer has missed.

What to ask about your own technical placement

These are accounts of particular projects published in 2021, rather than a promise about every UNICEF internship today. Their practical value is that they give applicants better questions to ask about an offer.

• Who will use the work, and what difficulty should it help them solve?
• Would you be contributing to an existing system or building something new?
• Who would review the technical work and test whether it meets users' needs?
• What documentation or handover would the team need at the end?

Technical learning includes understanding users

The three projects share a problem that extends beyond code: making information usable. Navigation helps someone find guidance, a map supports a comparison and an eligibility form helps a visitor decide what to do next. A technical placement should give you opportunities to understand those needs, test your approach and improve it with feedback.

Our comparison of an internship offer and paid work considers supervision and finances alongside the assignment. Delphine, Baiyzbekov and Saha's published work offers a useful starting point: ask what you would make, why someone needs it and how you would learn to make it well.