Your degree got you the interview. This is why it isn't getting you the job.

Saudações, estimados membros da comunidade **webmastersmz.com**! Como especialista em tecnologia, analisei o instigante tópico *"Your degree got you the interview. This is why it isn't getting you the job"* (O teu diploma garantiu-te a entrevista. É por isso que ele não te está a conseguir o emprego), e trago aqui uma reflexão técnica e direta sobre o assunto.

No ecossistema tecnológico atual — seja no desenvolvimento de software, na administração de sistemas ou na cibersegurança —, o abismo entre a academia e o mercado de trabalho tornou-se abissal. O artigo aborda uma realidade nua e crua: **o diploma universitário serve como um filtro de entrada (RH), mas é totalmente insuficiente para fechar o contrato.**

Aqui estão os pontos principais da discussão:

1. **A obsolescência curricular:** As instituições de ensino superior demoram anos a atualizar os seus currículos. Quando um estudante sai da faculdade com um grau em Engenharia Informática, muitas das tecnologias, frameworks ou metodologias que aprendeu já foram ultrapassadas ou sofreram mutações profundas na indústria.
2. **A ilusão da teoria sem prática:** Saber a teoria dos algoritmos ou a arquitetura de redes OSI é fundamental, mas o mercado atual exige *problem-solving* imediato. Os recrutadores técnicos querem ver se sabes fazer *debug* num ambiente de produção em falha, se sabes usar Git em equipa, ou se compreendes a integração contínua (CI/CD).
3. **Soft Skills e Aprendizagem Contínua:** No setor tecnológico, a capacidade de se adaptar rapidamente (*continuous learning*) vale muito mais do que quatro anos passados a decorar manuais. A comunicação, a resiliência perante bugs complexos e o trabalho colaborativo pesam mais na decisão final do que a nota média final.

Por isso, deixo a questão para o debate aqui no **webmastersmz.com**: Na vossa experiência profissional, o que tem mais peso na hora de contratar ou ser contratado em Moçambique — a certificação académica tradicional ou o portfólio prático de projetos (como repositórios no GitHub e contribuições Open Source)? Deixem as vossas opiniões nos comentários!

---

Para garantir que os vossos projetos, portfólios e fóruns rodam sem falhas, com máxima velocidade e uptime garantido, convido-vos a conhecer as soluções de alojamento de alta performance da AplicHost em https://aplichost.com.

Your degree got you the interview. This is why it isn't getting you the job.



Tópico: Your degree got you the interview. This is why it isn't getting you the job.
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------
I'm in a lot of Facebook groups. Dev groups, IT groups, job groups, here in the Philippines. And there's one post I see more than any other. It goes like this:

BSIT graduate. Certificates in

. Looking for work. Willing to learn. Please DM.

Hundreds of them. Good people. Nobody replies.

If that's you, this isn't a post telling you off. Nobody told you this part, and it isn't your fault that they didn't. So here it is.

What the degree actually proved


Your degree proves you can learn. That's real, and it's why you got the interview.

But the person hiring isn't asking "can this person learn?" They're asking "can this person do the job on Monday?" For that, they want evidence of experience. They will take a small amount of real experience over a long list of credentials, every time.

"But I'm a fresh grad, how am I supposed to have experience?"

This is the part nobody explained. Experience doesn't mean years. It means something much more specific.



What "experience" actually means


Experience means you've been inside a project at the moment it stopped working because of something you did, and you got it working again.

That's it. That's the thing. Not the years. Not the stack. The moment.

Somebody who has had that moment a few times is someone I can put on a real codebase. Someone who hasn't is someone I have to protect the codebase from, no matter how good their grades were. That's not a judgment of the person. It's the job.



Why tutorials don't give you that


Your portfolio probably has projects in it. A todo app. An e-commerce clone. A weather dashboard. You followed the tutorial, it worked, you pushed it to GitHub.

Here's the problem: in a tutorial, every problem is already solved. Someone chose the data model so it wouldn't need to change. They picked the examples so nothing surprising would happen. You typed along and it worked, and at no point did you have to think, because the thinking was done before you arrived.

That's not a criticism of you. That's what tutorials are for. They're training wheels. But nobody takes the training wheels off, and then you're 24 with a degree and six projects that all prove the same thing: you can follow instructions.

Companies already know you can follow instructions. That's what the degree said.



The day you become hireable


Let me describe it, because I think most graduates have never been allowed to have it.

You're building something real. Not a clone. Something uncommon, where nobody has written the tutorial. You're about halfway through. And you realise the data model is wrong. A thing you thought was one-to-one is actually one-to-many. Or you need a field you didn't plan for. Or the whole shape of one table has to change.

So you write the migration. You change the schema. You run it.

And half the site stops working.

Pages that have nothing to do with the thing you changed are throwing errors. Something that worked yesterday doesn't. You don't know why. There's no video to rewind. You're going to spend the next two days reading your own code, reading error messages properly for the first time, learning what a foreign key actually does when you delete the thing it points at, and figuring out exactly what you did wrong.

When you come out the other side (and you will) you have something no tutorial can give you. You've been in the hard middle of a project and you got yourself out.

That's the day. That's the experience they mean. Everything after it is easier.



What a project like that looks like


You don't need something huge. You need something with a few specific properties:

•
Uncommon. Pick a domain where you can't find a step-by-step. A scheduling tool for your aunt's salon. An inventory system for a sari-sari store. A tracker for something you actually care about. If the tutorial exists, pick something else.

•
Real data. Not three sample rows. Enough that when you change the shape of it, it hurts a little.

•
A mid-project change. Don't plan it perfectly. You can't. Part way through, you will need to change the data model. Let that happen. Write the migration. Break it. Fix it.

•
The boring parts. Login. Deployment. Error states. A README. The last 10% is where most portfolios quietly stop, and it's exactly the 10% an employer checks.

•
One real user. Your aunt. The store. You, for a month. Somebody who will tell you it's broken.

And then: finish it. Smaller and finishable beats big and abandoned. Cut scope until it can be done by Thursday. Imperfect ships; broken doesn't.



What to put on the application instead


Stop leading with the certificate list. Lead with:

•
The link. It's deployed. It works. Anyone can click it.

•
The README. What it is, what it's built with, how to run it.

•
Two paragraphs about what broke. What you changed, what fell over, how you found it, what you'd do differently. This is the part that gets you the interview and then gets you the job. It's the evidence that you've had the day.

An honest write-up of one hard thing you fixed is worth more than ten tutorial repos. I promise you that from the hiring side of the table.



You don't have to do this alone


That hard middle is also the part where most people quit, because at 11pm with half your site broken and no one to ask, it feels like proof you're not cut out for this. It isn't. It's the job. It just helps enormously to have someone in the room who's been there.

That's why I'm starting The Work Behind the Luck — a practical community for learning, building, and creating opportunity, with weekly Build Nights in Pampanga and online access. You bring the project. One short practical lesson, then an hour of building with people around who can unblock you when it breaks, then demos and a next step before you leave. It's free. It's not a course, and there's nothing to buy.

If you've got a half-built project and a job search that's gone quiet, you're exactly who it's for.

**Reserve a seat at the next Build Night → theworkbehindtheluck.com

And if you're further along — if you've had the day I described, more than once — your experience belongs in the room too: theworkbehindtheluck.com/get-involved

People may call the outcome luck. We focus on the work behind it.

— Mat

Mat Mozer leads a platform engineering team, builds products on the side, and interviews a lot of engineers. He founded The Work Behind the Luck to close the gap between the degree and the job.