Salary, Interviews, and Portfolios: What School Rarely Covers

Salary, Interviews, and Portfolios: What School Rarely Covers

I used to treat getting a developer job as a programming contest. Learn another framework, collect another certificate, and hope someone notices. That approach left out three practical questions: what value can you explain, how do you show it, and what are you willing to trade for the offer?

This is not a promise that a portfolio or a negotiation script will get you hired. Hiring is noisy and markets change. The useful goal is to make your evidence clearer and your decisions less random.

A portfolio is evidence, not a gallery

A recruiter does not need ten abandoned repositories. One or two finished projects are easier to evaluate. For each project, explain:

• the problem and who needed the solution;
• the constraint you chose to respect;
• the architecture and the part you personally built;
• one failure, trade-off, or security concern;
• how someone can run, test, or inspect it.

A short README with screenshots, setup steps, a live demo, and a small design note beats a list of buzzwords. If the project handles accounts, payments, or private data, describe the access boundary without publishing secrets.

GitHub's profile documentation is a useful reference for presenting work, but the profile is only the index. The repository itself should contain the evidence.

Interview preparation that does not feel like theatre

Memorising answers to every algorithm puzzle is not the same as being ready for an interview. Prepare stories from work you actually did. A simple structure helps:

1. context: what was broken or needed;
2. decision: which option you chose and why;
3. implementation: what you changed;
4. result: what improved or what you learned;
5. reflection: what you would change now.

For a technical interview, practise making assumptions visible. Ask about constraints, sketch the simplest design, name the failure modes, and test an example out loud. Interviewers can evaluate reasoning more reliably when they can hear it.

Salary is a range, not a personality test

Before naming a number, write down your target, a comfortable range, and the point where changing jobs no longer makes sense. Compare the whole offer: base salary, variable pay, equity, benefits, working hours, on-call expectations, location, learning opportunities, and contract risk.

Public salary surveys can provide a rough market signal, not a guaranteed price for one person. The Stack Overflow Developer Survey is useful for seeing how respondents report compensation and roles, but its sample and definitions do not map perfectly to every country or company.

Ask what the range is for the role and level. If the employer shares a band, respond to the responsibilities and evidence you bring rather than pretending the number is universal. Do not disclose a current salary if you are not required to; you can redirect to the expected range for the new role.

Red flags worth asking about

Ask who owns the code, how incidents are handled, whether “ownership” means unpaid overtime, how performance is measured, and why the role is open. Ask to meet the person who will review your work. A vague answer is information.

An offer can be financially attractive and still be a bad fit if the scope, security practices, or working hours are unclear. You are interviewing the company too.

A practical next week

Choose one project. Write its README as if a stranger must run it. Record three decisions and one mistake. Prepare a salary range from several relevant sources. Then apply to roles whose responsibilities match the evidence you can show now.

The point is not to look impressive everywhere. It is to make the right work easy to verify and to choose an offer with your eyes open.

References

• GitHub Docs: Customizing your profile
• Stack Overflow Developer Survey