Being a Software Engineer at IH

Job Descriptions: SE I · SE II · SE III

Progression Documents: SE I · SE II · SE III

You are a practitioner. Whether you’re an SE1, SE2, or SE3, the core of the work is the same: write good code, ship working software, learn from what you build, and invest in the people around you. What changes as you grow is the scope of what you take on, how independently you navigate it, and how much your growth lifts others. Great software is built by engineers who are supported, growing, and proud of what they ship.

Our systems touch residents in hundreds of thousands of homes: the app they use to pay rent, the portal for maintenance requests, the tools associates depend on every day. The code you write matters. When we get it right, people feel it.

(“Residents” are the people who live in our homes; “associates” are our employees.)

David Thomas and Andrew Hunt open The Pragmatic Programmer with a question that applies at every level:

“Care about your craft. Why spend your life developing software unless you care about doing it well?” — David Thomas and Andrew Hunt, The Pragmatic Programmer

Craft and Delivery

The core of this job is building software: writing code, reviewing it, shipping changes, and then doing it again.

Early on, your work is smaller and well-defined. The goal is not just to complete the tasks. Understand why a solution works, how it fits into the broader system, and what “done well” looks like on this team. You’re learning the codebase, the tools, the conventions, and the standard your team holds itself to. AI coding assistants are part of the modern toolkit. Use them to learn faster, not to skip the learning. Understanding why the code works matters as much as getting it to work.

As you grow into SE2 and SE3, the scope expands. You take on larger features with less definition, contribute to design and estimation, and move toward owning implementations end-to-end. By SE3, you’re not just executing work: you’re leading it, breaking it down for others, and driving it through to delivery.

At every level, the standard stays constant. Follow the conventions your team has agreed on. Write code that the next engineer (including future you) can understand and extend. Test your work. Review others’ PRs carefully and promptly. A good solution delivered is worth more than a perfect solution in progress.

On-call and production support are part of the picture from the start. Systems behave differently in production than in development, and your instincts sharpen fastest when you’re watching real behavior. By SE3, you’re setting up postmortems, identifying root causes, turning incidents into improvements, and looking for repetitive manual work that can be automated away.

When work stalls, act. Ask for help early. Waiting until you’re deeply stuck helps no one. Over time, remove the small blockers yourself rather than waiting for someone else to notice. That shift (from “I asked for help” to “I cleared the path”) is one of the clearest signs of growth.

Communication and Collaboration

Engineering is a team sport, and most of the leverage comes from how well information moves.

Good communication starts with asking questions: early, often, and without hesitation. Every clarifying question you ask saves someone time downstream. Listen carefully, synthesize what you hear, and write clear PR descriptions that give reviewers the context they need.

As you grow, the direction of information flow expands. You’re giving feedback on others’ code: clearly, kindly, and with the intent to improve the work. You’re contributing to team discussions, writing documentation that others actually use, and advocating for the decisions and practices your team has agreed on.

By SE3, communication is how you create leverage for the whole team. You’re writing things down: decision records, diagrams, system documentation that the whole team can build on. You’re flagging technical risks before they become delivery problems, and asking whether you’re building the right thing, not just building it right. Knowledge that lives in your head and nowhere else is a risk to the team.

Raise disagreements early and clearly. Your perspective matters, and diverse viewpoints make us stronger. Once a decision is made, commit to it fully. Modeling that behavior (saying what you think, then getting behind the call) is how teams stay honest and still move fast.

Learning and Curiosity

Continuously improving our craft is one of our engineering principles. The growth between SE1 and SE3 is substantial, and it does not happen passively.

Be curious. Treat every task as an opportunity to learn something: about the system, the domain, the tradeoffs, or the people around you. Read and understand the architecture decisions your team has recorded, and the reasoning behind them. When a convention seems wrong or outdated, ask about it; that is how standards evolve.

Stay curious about what is happening outside your immediate work. The further you go, the more it matters to understand how your system fits into the broader architecture and how your decisions ripple outward. By SE3, back those decisions with data and metrics rather than instinct alone.

Attend the Technical Architecture Guild (TAG), Solution Architecture sessions, and applicable Special Interest Groups (SIGs). Early on, your job is mostly to listen and build context. Over time, bring what you learn back to your team and, eventually, contribute your own perspective to those conversations. By SE3, sharing what you’ve learned (in SIGs, Monthly Learnings, or a team demo) is part of the role.

Growing Your Reach

Our vision is to delight our residents and associates with innovative solutions built by happy teams. Happy teams are made of people who invest in each other, starting from their first days on the team. That investment looks different at each level, but it starts here.

At SE1, your primary responsibility is yourself: do the work, learn the tools, ask good questions. At SE2, your reach begins to extend to your teammates: review their PRs, check in when someone is stuck, model a bias to action. At SE3, your reach is the team: you lead implementations, share knowledge broadly, and invest in the growth of the engineers around you.

Mentorship at SE3 is not a formal obligation. It follows naturally from having learned enough to help others learn faster. Pair with more junior engineers on work that will stretch them. Provide the context that helps them make better decisions, not just complete tickets. Help onboard new teammates. Ask “why” even in challenging situations, and model the curiosity and accountability you want to see.

As your reach grows, so does your role in building the team itself. Join interview panels and give feedback on candidates.

The best SE3s are not just strong engineers. They are engineers that SE1s and SE2s want to become.

From here, the IC track continues to SE4 and beyond, or you may find yourself drawn toward the Engineering Manager track if people leadership is where your energy goes. What both paths require is a foundation of technical credibility, good judgment, and genuine investment in others. That foundation is built here.