Take low pay only when the role teaches the skills you want, sits close to the career you are aiming for, and has a clear end date. Turn it down when it pulls you into unrelated work, forces an expensive move, or leaves no time to build toward something better.
What people tell me
I am finishing my degree or have just graduated, and the first thing I have been offered pays very little. It might be an internship doing bidding or account work instead of engineering, an offer in another city that would barely cover rent, or a job at a company that is not in the direction I want. I also have loans or family pressure. Should I take it, keep searching, freelance, or teach for a while?
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Judge a first role on what it teaches and where it leads, then on pay. But pay still has to cover your life.
- Low pay in the right direction is an investment. Low pay in the wrong direction is a detour you pay for twice.
- A far-away offer is only worth it if the salary survives rent, food and travel with something left over.
- If you accept, set a 6 to 12 month plan and keep building skills from the first week.
- Freelancing and teaching are valid bridges, but only with a written plan for how they lead into engineering work.
There is no single right answer, but there is a right way to decide
Almost every early-career engineer faces this choice, and the advice online swings between "take anything, experience is experience" and "never accept less than you are worth". Both are too simple. A first job is a trade: you give time and get money, skills, a line on your CV and people who can vouch for you. The question is whether the trade is good for you, right now, given your finances.
Over the years I have told some people to take a modest offer and others to walk away from one. The difference was never the salary alone.
The four questions that decide it
- Does the work build the skills of the career you want? An internship writing code, even for little money, compounds. An internship bidding on freelance platforms or doing account management, when you want engineering or cybersecurity, mostly teaches something else.
- Can you actually afford it? Work out the monthly numbers: rent, food, transport, loan repayments, money sent home. If the offer does not cover them, it is not an option, however good the learning.
- Is there a path out or up? Ask what happened to the last few people in the role. Were they promoted, given a raise, or did they leave after a year with good skills? A role with no visible next step needs a short time limit.
- Does it leave energy to keep growing? A job that demands long hours on unrelated work can stop you learning altogether, which makes the next switch harder.
A quick decision table
| Situation | My usual advice |
|---|---|
| Low-paid, but real engineering work with people who review your code | Take it, set a 12 month plan, negotiate at review time |
| Low-paid, unrelated work (sales, bidding, data entry) and you are still studying | Treat it as short-term income only, cap it at a few months, keep building projects |
| Offer in another city that barely covers living costs, in a role you do not want | Usually decline, and use the next one to three months to aim higher |
| Offer with a large company, low pay, long bench or training period | Accept only if you have no alternative, and prepare to switch within a year |
| Loans or family depending on you and no other offer | Accept, then plan your exit deliberately. Income stability is a legitimate priority |
| Choosing between freelancing, teaching and a junior job | Prefer the junior job if it is engineering. Freelance or teach only with a clear plan to show engineering output |
If you accept a low-paying role
Accepting is not settling if you do it with intent.
- Write down what you want from the role before you join: two technologies, one project you can talk about, one person who will vouch for you.
- Ask for engineering exposure early. Offer to automate a manual process, write internal tools, fix small bugs. Many people get pulled into better work simply by asking.
- Keep a learning block outside work, even five hours a week, so your skills keep up with the market rather than only with your employer's stack.
- Track your results as you go: what you built, what it saved, who used it. That becomes your CV and your case for a raise.
- Set a review date. At six months ask about growth and pay. At twelve months, if nothing has moved, start applying seriously.
If you decline
Declining only works if the next months are more productive than the job would have been. Give yourself a fixed window, usually one to three months, and use it fully: strengthen data structures and problem solving, polish two projects so they actually work as described, fix your CV and LinkedIn, and reach out for referrals rather than only applying on portals. If the window ends with nothing, revisit your standards honestly rather than drifting.
Freelancing, teaching or a job?
- A junior engineering job gives you code review, production experience and colleagues, which is the fastest way to grow in the first two years.
- Freelancing can pay better sooner but rarely provides review or mentorship, and client work can stay shallow. It works best alongside a portfolio aimed at a full-time role.
- Teaching keeps fundamentals sharp and pays steadily, but it only helps a software career if you keep building real projects on the side.
Whatever you choose, remember the choice is reversible. People who start in a modest role and keep learning routinely switch to much better positions within one or two years. What is hard to reverse is two years spent in work that taught you nothing you wanted.
Negotiating a little is normal
Even for first roles, it is reasonable to ask politely whether there is flexibility on salary, a relocation allowance, a review after probation, or a remote or hybrid arrangement that cuts living costs. The worst answer is no, and a well-mannered question never costs an offer at a reasonable company.
If you are still stuck
Before any job decision, work through Fourteen questions worth answering before you change jobs, and read What actually changes in your first two years as an engineer to see what a good first role should give you. If you want to talk through a specific offer, book a free 1:1 session.
Was this answer helpful?
Read next
- Fourteen Questions Worth Answering Before You Change JobsThe typical job change starts with one specific bad month, and within a fortnight the applications are out. Sometimes that is right, and often it produces a lateral move into a different set of problems discovered around month four. Fourteen heuristics for the whole arc: deciding, choosing, not being talked into or out of it, and leaving well.
- What Actually Changes in Your First Two Years as an EngineerInterviews test the small part of the job that is easy to test, and the rest is learned on site. Reading code as the main skill, how to ask a question that costs nothing, why small shipped changes beat large ones in progress, using code review as the fastest teaching you will get, and the four things that actually get people promoted, three of which are not about writing code.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.