TL;DR
- A senior developer is not someone with many years on their CV. It is someone who reduces technical risk, communicates trade-offs and delivers without needing daily supervision.
- In Portugal, trying to hire good seniors with a slow process, a generic role and a misaligned budget almost always fails.
- Useful technical tests assess real decisions: data, APIs, security, deploy, observability and maintenance. LeetCode rarely measures what matters in a B2B SaaS.
- The biggest mistake is hiring “a senior saviour” when the problem is lack of product direction, confusing architecture or accumulated technical debt.
- Before hiring, decide whether you need a permanent employee, freelancer or external team. Each model solves different problems.
What “senior” means in practice
There are many people in Portugal with the title “Senior Software Engineer” on LinkedIn who, in production, still need quite a lot of support. This is not a personal criticism. It is a normal consequence of companies that promote based on tenure, not impact.
For me, a senior developer has five concrete characteristics.
First, they know how to break down ambiguity. If you tell them “we need a customer portal”, they do not immediately start creating components in React. They ask questions about authentication, permissions, data sources, auditing, integration with ERP or CRM, SLAs, migration, support and who is going to operate it at 3 in the morning.
Second, they understand data. They do not have to be a DBA, but they do need to know when to use a transaction, when to create an index, how to read an EXPLAIN ANALYZE in PostgreSQL 16, why a migration can block writes in production and how to avoid N+1 queries. Anyone working in B2B SaaS, fintech, retail or healthtech who does not master the data lifecycle is building future problems.
Third, they communicate trade-offs. A decent senior does not just say “I would use microservices” or “I would use Supabase”. They explain operational cost, limits, dependencies, expected latency, impact on the team and the reversal path.
Fourth, they leave a trail. Readable pull requests, documented decisions, useful logs, minimum metrics, runbooks and tests in the right places. It is not bureaucracy. It is the difference between a team that can operate software and a team held hostage by the person who wrote the code.
Fifth, they know how to say “no”. In real projects, seniority appears when someone stops a beautiful but dangerous solution. For example, refusing a direct integration between checkout and ERP without a queue, retries and idempotency. Stripe's documentation on idempotency, at https://docs.stripe.com/api/idempotent_requests, should be mandatory reading for any developer who touches payments.
Before the role, understand the problem you want to solve
Many companies start with the job advert: “We are looking for a senior full-stack developer with React, Node.js, PostgreSQL, AWS, Docker, Kubernetes and good communication skills.” This is weak. It says nothing about the real problem.
Before publishing the role, write an internal one-pager with this:
- Product: what the person will build in the first 90 days.
- Main risk: performance, security, legacy, delivery speed, integrations, data or team.
- State of the stack: versions, technical debt, test coverage, deploy, recent incidents.
- Expected level of autonomy: will they lead decisions or execute within an already defined architecture.
- Success metric: reduce critical bugs, deliver a module, stabilise an integration, cut deploy time, improve the p95 of an API.
At Impact Origin, when we work with clients at a very early stage, including active clients of around two months who still have no defined billing, the first recommendation is rarely “hire an expensive senior right away”. Often it is to clarify product, data flow and operating model. Hiring a senior person to compensate for lack of focus is an expensive way to postpone a difficult decision.
The right question is: what risk does this hire need to remove?
If the risk is architecture, you need someone who has already operated systems with real traffic, real data and real failures. If the risk is product speed, perhaps you need someone pragmatic, good at cutting scope and delivering weekly increments. If the risk is a junior team, you need mentoring ability, code review and technical standards.
They are different profiles. Putting everything into the same advert reduces the likelihood of finding the right person.
Permanent, freelancer or consultancy: they are not equivalent
There are three common paths. All can work. All can go wrong.
Permanent employee makes sense when you want to accumulate internal knowledge, build an engineering culture and have a roadmap for 12 to 24 months. It is the best option for core product. The problem is time. Between sourcing, interviews, notice period and onboarding, 2 to 4 months can easily pass. For strong seniors in Portugal, assuming a total monthly cost below €4,000 is usually optimistic, especially if you are competing with remote European or North American companies. In addition to salary, factor in TSU, equipment, benefits, management and opportunity cost.
Senior freelancer makes sense for diagnosis, technical unblocking, migration, integration or temporary acceleration. In Portugal, rates of €45 to €90 per hour are common for experienced profiles, varying a lot with specialism and context. A 3-month mistake at €60 per hour, full time, costs around €28,800 before VAT. So do not hire a freelancer without weekly deliverables and clear acceptance criteria.
Consultancy or external team makes sense when you need an outcome, not just hands. The advantage is combining profiles: architecture, product, development, QA, DevOps. The disadvantage is that the hourly cost may seem higher. I say “seem” because comparing only hourly price is a trap. If an experienced team avoids 6 months of the wrong refactoring, hourly price is no longer the main metric.
The rule of thumb: if the knowledge has to stay in-house for years, hire. If you have a bounded problem, use a freelancer or consultancy. If you do not know how to diagnose the problem, start with a short technical assessment before hiring someone permanently.
How to design a technical process that does not put good candidates off
Good senior developers do not have patience for slow processes, generic tests and interviews where nobody can explain the current architecture. If your process has 6 stages and one of them is an unpaid weekend challenge, you will lose good candidates to more direct companies.
A decent process can have 4 steps.
1. Short screening, 20 to 30 minutes. Objective: understand motivation, availability, financial expectations, English, working model and context. Do not ask deep technical questions here.
2. Technical conversation, 60 minutes. No tricks. Ask the person to explain a system they built, a wrong decision they corrected, a production failure and a situation where they said “no” to product or management. Good seniors have scars. Bad candidates only talk about technologies.
3. Practical exercise, maximum 2 hours. Ideally paid if it is longer. The exercise should feel like real work. For example: “we have a Node.js 22 LTS API that creates orders, writes to PostgreSQL 16 and sends payment to Stripe API 2024-04-10. Design the failure points and propose changes to guarantee idempotency, auditing and retries.” This measures reasoning, not memorisation.
4. Pairing or architecture review, 60 to 90 minutes. Give them a small PR or a simple diagram and ask for a review. What you are looking for is the quality of questions, ability to prioritise and clarity in communication.
Avoid LeetCode as the main filter for normal B2B SaaS. Algorithms matter in certain domains, of course. But for most business products, it is more valuable to assess HTTP, queues, SQL, authentication, permissions, observability, deploy and maintenance. The current HTTP specification is in RFC 9110, at https://www.rfc-editor.org/rfc/rfc9110. If the person is going to design APIs, they should know at least the basic concepts: idempotency, status codes, cache, headers and method semantics.
Strong signals and dangerous signals in an interview
There are answers that tend to separate real seniors from merely experienced profiles.
A good sign is the person asking about production data. Table volume, p95 and p99 of critical endpoints, number of tenants, RPS, payload sizes, deploy time, error rate, monthly cloud cost, mean time to recovery. Even if you do not have these numbers, the question shows maturity.
Another good sign is talking about reversibility. Feature flags, two-phase migrations, small deploys, rollback, version compatibility, idempotent scripts. This is adult engineering.
I also value candidates who know how to choose boring technology. PostgreSQL 16, Redis when it makes sense, simple queues, structured logs, OpenTelemetry, predictable CI. Not everything needs Kubernetes, Kafka and distributed architecture. We have written quite a lot about this in other contexts: technical complexity before real need is a debt, not a medal.
Dangerous signals:
- They talk about “rewriting everything” before understanding the system.
- They cannot explain failures they caused or helped fix.
- They only evaluate technology by personal preference.
- They do not ask about users, operations, support or data.
- They treat security as a final task.
- They undervalue tests because “a senior does not need them”.
- They never mention logs, metrics or alerts.
In healthtech and fintech, for example, permissions, auditing and traceability are not details. OWASP ASVS 4.0.3, at https://owasp.org/www-project-application-security-verification-standard/, is a good reference for discussing authentication, session management, access control and validation. You do not need to turn the interview into a security exam, but a senior should understand that sensitive data changes the architecture.
The common trap: hiring years of experience instead of context
The gotcha I see most often is confusing “10 years of experience” with “10 years of relevant decisions”. A person may have spent 8 years on the same product, with manual deploys, little scale, little business pressure and almost no responsibility for operations. They may be competent, but perhaps they are not the right person to lead a SaaS that needs integrations, billing, tenant-based permissions, observability and weekly releases.
The opposite also happens. Someone with 5 or 6 very intense years, in good teams, with exposure to incidents, product and clients, may be more senior in practice.
So interview for context.
Ask:
- What technical decision did you make that you later had to reverse?
- How did you migrate data without stopping production?
- How do you design permissions by organisation, team and user?
- How do you investigate a p99 at 2 seconds when the p50 is 80 ms?
- What would you do if a queue started accumulating 100,000 jobs?
- What logs do you want to see when a payment fails?
- How do you separate bug, incident and technical debt?
The answers do not have to be perfect. But they do have to show method. A senior does not need to know everything. They need to know how to reduce uncertainty.
Another trap is hiring a “senior full-stack” for everything: frontend, backend, cloud, UX, security, product, support and team management. That is not a role. It is a list of anxiety. You can find very versatile people, but nobody is excellent at everything. Define where you accept depth and where you accept sufficiency.
How not to lose good candidates during the process
Portugal is no longer an isolated market. A senior developer in Lisbon, Porto, Braga, Coimbra or remote from the interior can work for European or American companies, or distributed teams. If your process is slow, opaque or poorly paid, you lose.
Simple things make a difference.
Publish the salary range. If you cannot publish it, at least say it in the first conversation. Hiding the budget wastes time on both sides.
Explain the working model clearly. Remote, hybrid, mandatory days, time zone, equipment, meeting hours. “We are flexible” without details means nothing.
Show the real stack. Do not just say “AWS”. Say whether you use ECS, Lambda, RDS, S3, CloudWatch, Terraform, GitHub Actions. Give versions when relevant. Node.js 22 LTS, PostgreSQL 16, React 19.NET 8, Python 3.12. This attracts people who like rigour and prevents misunderstandings.
Prepare the interviewers. Nothing kills a senior hire faster than an interview conducted by someone who cannot answer basic questions about product, architecture or decision-making process.
Give quick feedback. Even if it is “no”. A 48-hour deadline after each stage is reasonable. A week of silence conveys disorganisation.
And do not sell chaos as opportunity. If there is legacy, say so. If there is pressure, say so. If the team is small, say so. Good seniors do not run away from difficult problems. They run away from companies that hide reality.
Conclusion
Hiring senior developers in Portugal without getting burnt requires clarity before sourcing, technical assessment linked to real problems and honesty about money, context and risk.
My opinion is simple: do not hire seniority by title. Hire decision-making, operational and communication ability under uncertainty.
If you are facing a similar problem, book a call at https://impact-origin.com/agendamento.
