Tech jobs explained: what you'd actually do all day
Job adverts in tech are written in a language nobody speaks. "Provide first-line support to end users in line with agreed SLAs" tells you precisely nothing about whether you'd enjoy a Tuesday. So here's the honest version. Below are the three entry roles you're most likely to land in, each walked through as a real day, followed by the myths worth binning and a straight look at who actually thrives in this work. By the end you should know whether tech is your kind of tired.
First-line support: the service desk day
You start early, often before the people you support. The first job of the morning is the queue: overnight tickets, the automated alerts, the four emails from someone whose password expired at midnight. You triage before you fix - what's urgent, what's blocking a whole department, what can wait until eleven.
Then the phone starts. The rhythm of a service desk is interruption: a call, a ticket, a walk-up at the desk, a message from someone who'd rather ask you directly than log anything. Password resets. A laptop that won't join the Wi-Fi. A printer nobody has ever loved. Someone convinced their emails have vanished when they've actually dragged the folder somewhere odd. You fix, you log, you move.
The hard hour is whenever something big breaks. The file server drops or the internet goes down at a site. Suddenly the queue floods while thirty people all decide to ring at once. Your job in that hour isn't heroics - it's staying calm, telling people honestly what's happening and keeping the tickets straight so nothing is lost while the seniors work the actual fault. Learning to be the composed voice in a small crisis is the real skill of the role and it transfers to every job you'll ever have.
What people don't expect is how much of it is talking. You spend your day translating: turning "it's not working" into a diagnosable problem, then turning the fix back into words a person can follow. The other surprise is how quickly you become known. Fix something well for a department and they'll ask for you by name within a fortnight, which is oddly lovely.
Your manager is quietly watching two things: whether you update your tickets honestly and whether you escalate at the right moment. Sitting on a job for three days because you didn't want to look stupid is the one genuine sin. Say "I'm stuck" out loud and you'll be trusted with more, faster.
Junior developer: the build day
Slower, quieter and far less glamorous than films suggest. Most development teams start with a stand-up: ten or fifteen minutes where everyone says what they did yesterday, what they're doing today and what's in their way. As the junior, your honest answer is often "still on the same thing" and that's completely fine.
Then you're heads-down. A ticket describing something small - a button that should be disabled, a form that accepts nonsense, a report pulling the wrong dates. You read the existing code to work out how it currently behaves, change the smallest thing that could work, test it, then open a pull request so someone senior reviews it. That review is the actual education. Expect comments. Lots of them. They're not an insult; they're the fastest teaching you'll ever get for free.
The hard hour is being stuck. Genuinely stuck, an hour deep, staring at something that should work and doesn't. Every developer alive lives there regularly. What separates the ones who last is a rule they learn early: try properly for a while, then ask, showing what you tried. Nobody minds a question with working attached.
The unexpected part is how much of the job is reading rather than typing. Code that already exists, documentation, other people's changes. And how social it is - pairing with someone, arguing gently about how to name a thing, explaining your change to a tester. The lone genius in a hoodie is largely fiction.
What's watched here is whether your work comes back for the same correction twice. Take a review comment, actually apply it everywhere it applies and you're already ahead of most juniors.
Field and onsite technician: the moving day
If sitting still all day sounds like a slow death, this is your version. Field work means going to the problem: installing kit, swapping hardware, running cables, setting up new starters, doing the jobs a phone call can't fix.
The day is a route. A list of visits, a boot full of kit, a driving licence doing a lot of work. You might image ten laptops at a school in the morning, fit a new access point in a warehouse after lunch, then finish at a small office where nobody can print. Between jobs you're updating tickets from the van and ringing ahead so people know you're coming.
The hard hour is the job that turns out to be nothing like the ticket said. You arrive expecting a broken monitor and find a cupboard of ancient equipment held together with hope, with someone hovering asking how long it'll take. Managing expectations politely while you work out the real problem is most of the craft.
What nobody expects is the customer-service side. You're the face of the IT department for people who've never met anyone from it, so how you leave a room matters as much as whether the machine works. Tidy your cables. Take the packaging with you. Tell them what you did in plain words. Managers hear about the engineer who was pleasant far more often than the one who was fast.
Summer is the season here. Schools, colleges and offices do their big equipment refreshes when the buildings are empty, which is why temporary and junior hands often get taken on across the holidays.
Myths vs reality
"You need to be a maths genius." You need to be patient. Entry-level tech is far more about working through possibilities in order than about clever calculation. The people who wash out are usually the ones who guessed rather than checked.
"It's all coding." Most tech jobs involve no coding whatsoever. Support, networks, security, hardware, testing, infrastructure - enormous careers, no code required, though a bit of scripting eventually makes any of them easier.
"You work alone in the dark." You work with people constantly, which is exactly why communication is screened for as hard as technical ability. If you hated the idea of talking to strangers, first-line support would be the wrong door.
One more worth flattening: "everyone in tech has a degree". Look at the actual composition of any UK service desk and you'll find people who came in through apprenticeships, career changes, repair shops and pure stubbornness. The industry cares what you can do on Thursday.
Who thrives here (and who doesn't)
Tech suits people who enjoy the moment a problem gives way. If you're the sort who'll happily lose an hour to working out why something isn't behaving, you already have the core trait and everything else is learnable. It rewards the methodical, the ones who write things down, the ones who ask the boring question first.
It also suits people who like being useful in an obvious way. Support work gives you a dozen small wins a day and someone visibly relieved at the end of each one.
It suits you less if you need to be right immediately. Tech will make you look daft regularly and in front of people, so you have to be able to shrug and carry on. It's a poor fit too if you find repeated questions maddening, because you will reset the same password for the same person more than once. And if you want a job that ends completely at five, choose a team without an on-call rota, or aim at development rather than infrastructure. If you're under 18, check which tech jobs are open at 16 first, because the doors open unevenly before your eighteenth birthday.
The honest summary: tech work is more sociable, more practical and less mathematical than the outside picture suggests. The days go quickly because something is always mildly on fire. If that sounds appealing rather than exhausting, you'll probably love it. Start with our guide to getting your first tech job with no experience, browse the rest of the series at the tech hub or go straight to the source and browse live tech jobs near you.