Building Your Career in IT

The IT job market (as of 2026)

IT is a large field to build a career in. Statistics Netherlands (CBS) counted 622,000 ICT workers in the Dutch economy in 2024, almost twice the 336,000 of 2010, working in every sector, not only at IT companies. Across the European Union, Eurostat counted more than 10 million ICT specialists in 2025, 5.0% of all employment; in the Netherlands it is more than 1 in 20 employed people. The EU's Digital Decade target is 20 million ICT specialists by 2030, so demand is expected to remain.

Demand is not the same everywhere, though. After the peak in early 2022 the number of open ICT vacancies in the Netherlands fell; CBS figures put it at roughly 15,000 at the end of 2025. For people starting out, that means more competition for junior roles, and more reason to show evidence of what you can do rather than only listing courses. The field is also far from balanced: according to Eurostat, 19.5% of ICT specialists in the EU are women.

In the United States, the Bureau of Labor Statistics (BLS) projects that computer and IT occupations will grow faster than the average for all occupations from 2025 to 2035, with about 280,000 openings a year. The median annual wage in these occupations was $109,470 in May 2025, against $50,980 for all occupations.

Roles and how they connect

A career path is the sequence of roles a person moves through over time, and the skills and experience that make each move possible. In IT the paths branch and cross: a service desk employee can become a system administrator, a network engineer or a security analyst, and a system administrator can move into cloud, automation or architecture. Few people follow a plan they made at the start, and that is fine.

Job titles differ between employers, so read the tasks in a vacancy, not just the title. These are common starting and next roles:

The European e-Competence Framework

The European e-Competence Framework (e-CF) is a European standard, EN 16234-1 (version 4.0, published in 2019), that describes the competences IT professionals use, with proficiency levels for each, in a common language that works across countries, employers and job titles. It lists 41 competences, grouped in five areas that follow the life of an IT service from planning and building to running it, enabling the organization and managing the work.

You will rarely be asked about the e-CF in an interview, but it is useful in two ways. Some employers use it to describe roles and competence profiles, so you may meet its terms in a vacancy or a development plan. And it is a neutral checklist when you plan your own growth: which competences does the role you want ask for, and which have you already shown?

Similar frameworks are used elsewhere: in the United States, the NICE Workforce Framework for Cybersecurity (NIST SP 800-181) for security roles, and in the United Kingdom, SFIA (the Skills Framework for the Information Age) is widely used. Check which one your employer or the vacancy refers to.

Building experience

The classic problem: junior vacancies ask for experience, and you need a job to get experience. The way out is to create evidence of practical skill in other ways:

• A home lab: an old PC or a small single-board computer with a hypervisor, a few virtual machines, a domain, a firewall. Breaking and fixing your own systems teaches more than any video. See Learning Continuously.
• Volunteering and side work: the IT of a sports club, a foundation or a relative's small business. It is real work with real users, and it gives you references.
• Internships, traineeships and apprenticeships (in Dutch: stage): many employers hire juniors this way, and career switchers can often find traineeships that combine training with paid work.
• Your current job: even outside IT there is often a spreadsheet to automate, a process to document or a small tool to set up. That counts, if you can describe it concretely.

A technical portfolio

A technical portfolio is a small, public collection of your own work that shows what you can do: scripts and small programs in a Git repository, write-ups of how you built or fixed something in your lab, documentation you wrote, contributions to an open-source project. It turns a claim on your CV ("knowledge of PowerShell") into something an employer can open and read.

A portfolio does not need to be large. Three things done well beat thirty half-finished ones:

• Each project has a short README: what problem it solves, how to run it, what you learned or would do differently.
• Write-ups explain your reasoning, including what did not work. That shows how you think, which is what interviewers want to know.
• Recent and maintained beats impressive and abandoned.

Writing a CV

A curriculum vitae (CV) is the short document that summarizes your work experience, education, skills and qualifications for an employer; in American English it is usually called a résumé. Its job is not to tell your whole story but to earn you a conversation.

Writing bullets that say something

Most CVs describe duties. Strong CVs describe results. For each role, write a few bullets that answer: what did you do, how much or how often, and what changed because of it? Compare:

- Responsible for handling tickets and helping users
- Knowledge of Windows, Linux and networking
- Good communication skills, team player

- Resolved around 25 service desk tickets a day for 600 users,
  about 70% at first contact
- Wrote 12 knowledge articles on VPN and MFA problems; repeat
  calls on those topics fell noticeably in the following quarter
- Automated new-account checks with a PowerShell script, cutting
  onboarding preparation from 40 to 10 minutes per employee
- Home lab: Proxmox with Windows Server, Active Directory and a
  pfSense firewall; write-ups linked in my profile

The second version shows skills instead of claiming them: "communication skills" becomes "wrote 12 knowledge articles". Use real numbers you can explain in an interview; an approximate number you can defend is better than a precise one you cannot. Never claim a result your team achieved as yours alone, and never inflate it: reference checks and technical interviews find out.

Interviews

Interviews for IT roles usually mix three kinds of questions: motivation (why this job?), behavior (how did you handle a situation?) and technical (how would you troubleshoot this?).

The STAR method

The STAR method is a way to structure an answer to a behavioral question ("tell me about a time when...") in four parts: the situation, the task you had, the action you took and the result. It keeps answers short and concrete, and makes sure you talk about what you did, which is what the interviewer is trying to find out.

Amara Okafor, applying internally for a problem manager role at Kestrel Energy, is asked: "Tell me about a time you improved something without being asked."

Situation: On the service desk I noticed we were getting the same
           VPN error, "certificate not trusted", several times a day.
           Each call was solved on its own with a reconnect.
Task:      Nobody owned the pattern, so I decided to find out if it
           was one problem rather than thirty incidents.
Action:    I searched the ticket history, found 31 tickets in two
           weeks, all from laptops on one VPN gateway, and raised a
           problem record (PRB-0219) with the list attached. I wrote
           a workaround article (KB-0388) so colleagues could link
           new calls to it, and showed the pattern to Tomasz in the
           NOC.
Result:    The NOC found an expired intermediate certificate on that
           gateway and replaced it in a planned change. The calls
           stopped within a day. Since then I check ticket trends
           every Monday.

The answer takes about a minute to say. It contains numbers, names the people who did the fix, and ends with what she learned and still does. Prepare four or five stories like this before an interview: a problem you solved, a mistake you made and what you did about it, a difficult user or colleague, something you learned quickly, and something you improved. Most behavioral questions can be answered with one of them.

Technical questions

Technical interviews for junior roles rarely test whether you know everything. They test how you think when you do not.

• Think aloud. For a scenario like "a user cannot reach the intranet", talk through your steps: what you would ask, what you would check first and why. A structured method is exactly what they want to hear.
• Ask clarifying questions. "Is it one user or everyone? Wired or wireless?" shows the habit of gathering information before guessing.
• Say when you do not know, then say how you would find out: "I'm not sure what that flag does. I'd check the man page or the vendor documentation before using it in production." That answer is worth more than a confident guess.

Growing into the next role

Once you have a job, the fastest growth usually comes from the people around you rather than from courses alone.

Mentorship

Mentorship is a working relationship in which a more experienced person regularly helps a less experienced one grow, by sharing experience, giving honest feedback and helping them think through choices. A mentor can be a senior colleague, someone in another team or someone outside your organization. It does not have to be formal: a monthly coffee with a colleague whose work you admire, with a few questions prepared, already works.

Ways to make the most of it:

• Bring specific questions ("how did you decide to move from networking to security?") rather than "any advice?".
• Ask for feedback on real work: a ticket note, a script, a change plan. Then act on it, and say what you changed.
• Shadow someone in the role you want, for example a change review, an on-call shift or a problem investigation.
• Later, mentor someone yourself. Explaining what you know shows you where your own understanding is thin.

Making the move

Talk to your manager about where you want to go; managers can only support goals they know about. Many organizations have a yearly development conversation, and some a training budget. Take on tasks that belong to the next role, such as writing a script, joining an incident review or owning a small change, so that by the time you apply you can point to work you already did.

Certifications can help you get past the first screening and give structure to your learning; choose them for the role you want, not for the number. How to choose and maintain them is covered in Learning Continuously, and AI-related certifications in Using AI at Work. In the Netherlands, check whether a collective labor agreement (cao) applies to your employer: it often sets salary scales, training rights and working hours, which helps when you negotiate. In the United States and the United Kingdom, check your contract and, if your employer has one, the union agreement.

Feeling that everyone else knows more than you is very common in IT, especially after a move; see What Makes a Good IT Professional. Growth also needs energy over many years, which is why Health and Sustainable Work is part of a career too.