Build a portfolio that does the talking
Hiring managers repeatedly say the same thing: a small number of well-documented, finished projects beats a long list of half-built ones. Pick two or three projects that show range, for example one that demonstrates a technical depth (a working API, a data pipeline, a small distributed system) and one that shows product judgment (a usable interface solving a real problem). Write a short README for each explaining the problem, the decisions made, and what you would do differently, since employers read the explanation as much as the code.
Keep the portfolio current. A project last touched three years ago signals stagnation even if the work itself was good; a recently updated repository, even a modest one, signals active practice. If your target roles involve data or infrastructure rather than visible applications, a portfolio can still work in the form of documented analyses, infrastructure-as-code repositories, or written technical case studies.
Contribute to open source, deliberately
Open-source contribution is one of the few ways an early-career candidate can produce a public, verifiable, third-party-reviewed record of technical collaboration before they have a job. Start small: fixing documentation, triaging issues, or resolving a well-scoped 'good first issue' label builds both familiarity with a codebase and a visible commit history. Reviewers' comments on your pull requests are also free, high-quality technical feedback that most early-career developers otherwise struggle to obtain.
Choose projects connected to the technology stack you actually want to work in professionally, not the most famous project available, since relevance matters more to a hiring manager than fame. Consistency beats intensity: a handful of merged contributions spread over months demonstrates sustained interest more convincingly than a single large burst of activity around interview season.
Network without it feeling transactional
The most durable professional networks are built before you need anything from them. Attending a local ACS chapter meetup, a community college alumni event, or an industry meetup with no immediate agenda, simply to learn what others are working on, builds relationships that later produce referrals and honest advice. When you do need something, such as an introduction or a referral, ask specifically and make it easy for the other person to help, rather than sending an open-ended request.
Online, a professional presence on LinkedIn or a technical blog works best when it documents what you are actually learning or building, rather than reposting generic content. Recruiters and hiring managers routinely check candidates' public activity, so a modest, authentic record of ongoing learning is more persuasive than an inflated but static profile.
Interviews and technical assessments
Technical interviews for U.S. tech roles commonly combine a live coding exercise, a take-home assignment, or a system-design discussion with a set of behavioral questions assessing collaboration and judgment. Prepare for both halves separately: practice explaining your reasoning out loud while solving a problem, since interviewers usually weight process as heavily as the final answer, and prepare two or three concrete stories that show how you handled conflict, a mistake, or ambiguity, since almost every interview loop includes this kind of question.
For take-home assessments, resist the urge to over-engineer; a clean, well-tested solution to the stated scope, with a short note on tradeoffs you would explore given more time, is usually rated more highly than an elaborate but incomplete attempt. Always ask what the assessment is evaluating for if it isn't stated, since this materially changes how much time to invest and where to focus.
- Practice narrating your reasoning aloud, not just producing correct code
- Prepare specific stories covering conflict, failure, and ambiguity
- Scope take-home tasks tightly rather than over-engineering
- Ask what a given assessment is actually evaluating for
Negotiating pay with confidence
Use published data as your anchor before any conversation: BLS Occupational Employment and Wage Statistics and the Occupational Outlook Handbook give median and percentile pay by detailed occupation and, in many cases, by metropolitan area, and are a credible, neutral reference point that hiring managers cannot easily dismiss. Corroborate with recent postings for comparable roles at similar-sized employers in your metro area, since national medians can understate or overstate local reality.
Treat the full offer, not just base salary, as the subject of negotiation: signing bonus, equity, remote or hybrid flexibility, professional development budget, and start date can all move even when base salary is fixed by a banding system. Always negotiate after receiving a written offer, never before, and always in writing once terms are agreed, so there is no ambiguity later.
Switching careers into tech
Career changers routinely underestimate what they bring and overestimate the size of the skills gap. Domain expertise from a prior career, whether in finance, healthcare, logistics, or education, is genuinely scarce and valuable when combined with technical skill, since most technology teams need people who understand the business problem, not only the code. Frame prior experience explicitly in applications: a former nurse moving into health-tech, or a former teacher moving into edtech, should say so directly rather than treating the earlier career as irrelevant.
Choose an entry point that matches your risk tolerance and finances: a part-time community college certificate while still employed is lower-risk than quitting for a full-time bootcamp, while a Registered Apprenticeship offers a paid middle path. Expect the first role after a switch to be a genuine step down in seniority relative to your prior career; treat it as the price of entry rather than a signal that the switch was a mistake.
Avoiding burnout
Technology work has a genuine burnout risk, driven by always-on tooling, unclear scope, and a culture in some workplaces that rewards visible overwork. The most reliable protection is structural, not motivational: agree explicit scope and deadlines before starting a piece of work, push back on ambiguous, open-ended commitments, and protect a hard boundary around notifications outside working hours rather than relying on willpower in the moment.
Watch for early warning signs rather than waiting for exhaustion: declining code quality, avoidance of tasks you previously enjoyed, and irritability in routine meetings are common leading indicators. Talking to a manager or mentor early, framed around workload and scope rather than personal failing, is far more effective than waiting until performance has already visibly declined, and professional bodies including ACS chapters can be a useful outside sounding board when a workplace conversation feels difficult to start.