_edited.png){kind=logo}
Integrity's internship program goes beyond just technical skills.
When people are hiring “software developers,” they are often thinking “coders.”
Coding is definitely key for software development, but technical skills are also the easiest to acquire. Certain characteristics, like being a team player, problem solving, and empathy, are very important to a good hire, but these can take a long time to cultivate—they aren’t easily taught.
So, when we were designing our internship program, we knew we wouldn't have enough time and influence to deeply shape someone's character. We also knew we couldn't just pass on a set of technical skills if we wanted our interns to stand out in the job market.
In order to give our interns an advantage in the market, we decided we'd include workflow management and architectural skills.
Why did we do this?
Well, in many organizations, a software developer's job boils down to one function: cranking out as much code as possible to get the feature we assigned to you completed by the deadline that we also assigned you. The software planning is done by an entirely different group of people: managers, architects, designers. Anything that involves "thinking" at a higher level about the software is done for the developers, and they are typically discouraged from challenging it.
In environments like this, most developers never have the chance to do things like:
Set priorities for their team's development
Choose the best tech stack for the project
Decide which team members should work on which tasks
Forecast a project timeline
Create a genuine domain model of the problem area that isn't just an in-code replication of the database
At Integrity, all of our developers do the things listed above all the time. We wanted our interns to develop those skills as well. We wanted them to enter their software development careers having a breadth of experiences normally reserved for senior devs or architects.
In short, we wanted them to provide a level of value that most junior devs can't.
Day one of the internship was not setting up Visual Studio or learning how to make controllers in an API; it was how to manage work items as a team for maximum flow using Kanban.
We showed them the importance of small batch sizes and the impact this had on quick delivery and feedback. We taught them how to incorporate and adapt to changes users request. "The demo is where you get the real requirements," is something we said regularly.
We showed them how to gather requirements, how to write user stories, how to define acceptance criteria, and how to work with stakeholders to make sure those things were right. We gave them experience in producing requirements as well as running demos for the purpose of soliciting changes.
We taught them how to approach their work by swarming—putting as many people on the same user story as possible. We taught them that it’s ok to have more than one person at a single machine writing code together and how that can actually get a feature delivered more quickly.
When it came to tackling the actual code, we taught them to operate like a team of architects.
We showed them how to use Domain-Driven Design to design software that reflects the actual business. We taught them how to decide between entities and value objects and how to model invariants and business rules in the system.
We had them build the software using principles and patterns like separation of concerns, dependency inversion, and unidirectional data flow.
We had them drive out code from unit tests and drive out unit tests from code.
In sum, we wanted them to understand why you wanted code to be a certain way and the concrete benefits of doing so instead of just saying things like, "Don't put data access in the controllers because you shouldn't do that." We also wanted them to know when to break the rules.
It has been our experience that many software developers—even developers who have years of experience—have not had the opportunity to work in these areas at this level. They can write code to fulfill the task you assign them, but they struggle to solve business problems with software or think of the best way for teams to get software out the door.
By making these higher-level considerations a priority with our interns, we passed along those skills to them. That's extra value they can bring to any organization, and it makes them competitive not only with other new developers, but even mid-level or perhaps even senior developers.
Did it work?
The mother of one of our interns occupies a role where she is primarily responsible for planning the execution of software initiatives and coordinating the various developer teams. She was talking with her son one night about how they planned to approach something, and he replied, "I don't think Integrity would do it that way. I think they'd say to get it in front of the users as quickly as possible and respond to their feedback."
So, yes, I think our interns will do just fine.