In u2i we’ve been hiring students for years. The thing we absolutely value is the fresh and open-minded approach students tend to bring to the company. They usually have a different view on things that our senior staff have been doing in one particular way for years. Also, given the right environment they can grow into awesome developers with a quickness.
All that said, we’ve never really had very junior people joining u2i. We’ve been aiming at more experienced students that already took their first steps in other companies.
One day, an idea came into our heads — “What if we’re missing something?”
We decided to give it a try.
The Idea Behind the Internship
The sad truth of most of the universities is that they miss a lot when it comes to teaching software engineering. Projects focus on one particular engineering problem without considering the big picture and various challenges that show up. The classes often utilize outdated engineering practices and tools.
We wanted to give students a chance to work on a real product. Ideally, that would involve working with one of our regular clients, however it was impossible at the time because of our current arrangements with clients.
We set up an internal project. There are a lot of small things that we struggle with on a daily basis that can be improved with software, so we picked one of the problems and made a project out of it.
When it comes to organizational things, we decided to build a team of a few interns (4 to 6), that would work in the same way u2i’s regular employees work.
Besides that, we didn’t want to differ internships from regular work at u2i (that means pair programming, agile process and constant collaboration with clients).
We involved a few employees in the internship: a scrum master to make sure the team can do its work without obstacles, a product owner who can define the project (their client) and a few “mentors” who could help them if they have problems with technology.
How We Interviewed Candidates
The recruitment process for the internship was very similar to our usual recruitment. The major difference was that we didn’t expect candidates to have in-depth knowledge of any technology.
The first step was an automated coding test. We expected to get a lot of applications and we were aware that not all candidates would advance to the interview stage. We knew it’s not a perfect solution, but unfortunately it’s the only feasible one.
Most of the automated coding tests check hardcore algorithmic and speed-coding skills. We’re a software engineering company, far from doing abstract mathematical things.
That’s why we created a small workaround — we picked a few very easy programming tasks and set the time limit to a few hours.
This way our candidates didn’t have to work under a lot stress and didn’t have to hurry to solve these tasks.
Furthermore, it allowed us to select those who are comfortable writing code and carefully test their solutions.
After this initial stage, our 150 applicants shrank down to a pool of just over 40.
40 is still too many to interview (especially for a company of our size), so we still needed another way to narrow down the list of candidates.
We did it just like every HR professional would do it. We went through their resumes.
As I’ve mentioned before, we didn’t care much about prior experience.
Still, we highly value students that do more than just what teachers tell them to.
When reading resumes, we looked for cool side projects, participation in student organizations and the most basic knowledge of various programming languages, frameworks and tools. We looked for people who like playing with technology.
This left us with 24 people, which was a doable number of interviews.
There were two core competencies we wanted to check during the interview.
The obvious one was technical skills. We wanted to see if each candidate knew the very basics of software engineering, how they approached problems and if they felt comfortable getting their hands dirty and writing simple code in their favorite programming language. Yes, we used whiteboard for that.
The other thing was soft skills. No one works alone at u2i; every single developer works within a team and communicates directly with clients. It’s a part of our culture, so naturally we wanted to hire students who fit into it. Soft skills are often mistaken for being overly open and enthusiastic. The thing we really care about is being able to explain things to other people and work together on solving problems. That’s crucial for a positive and effective work atmosphere.
A Few Mistakes We Made
There were three important lessons we learned on our first approach to internships, mostly due to wrong assumptions we made.
Let’s start with the number of interviews. We had a pretty tight timeline, so we needed to do all of them in two weeks. We decided to optimize things a little bit and squish as many interviews into a single day as possible. It’s didn’t take long until we realized that 5 interviews in one day is a bit too much for a recruiter. Proper and in-depth interviewing can be very exhausting, and not only for candidates.
The second thing was giving feedback. If, after a regular interview we decide not to hire someone, we do our best to provide them with some feedback. We like to be clear on why we didn’t hire someone and in some cases we are able to give them advice on how to become better developers.
We hoped to do the same thing during the internship recruitment, but once again the number of candidates made that an impossible goal. We ended up sending general messages to most applicants, with a few exceptions if there were obvious things they could easily improve.
The last mistake was our skepticism towards 1st year students. We assumed that they would lack certain engineering knowledge usually gained in the later years of their studies. For some time we didn’t even consider inviting them for an interview, but later we decided to give them a chance. It turned out some of them have comprehensive knowledge (especially for a 1st year student). We even hired one of them.
And a Few Things That Went Well
On the other hand, some things went absolutely fantastic.
There’s a known bias that during interviews interviewers remember the first and the last person the most (and often make decisions in their favor). We didn’t want order to be a factor in our process, so we decided to make decisions right after each interview. This worked really well. A few days later we noticed that we don’t remember most of the interviews and if we held the evaluation off, it would’ve been impossible.
The other thing that went well was that we were able to hire people who make up a great team.
Our experiences with building teams is that teams that consist of very similar people are not especially effective. One of our goals was to hire people with slightly different sets of skills and personalities.
Before the interviews, we agreed on what kind of skills could be useful for the team to have.
We ended up with a great, complimentary team.
There’s a frontend expert, rails passionate, a guy who knows good engineering practices, all sharing knowledge. This all works well both for them (knowledge sharing) and for the project.
Surprisingly, we also ended up with a mix of personalities. There are interns who bring a lot of energy to the team, as well as people who calm the team down in case of crisis. It’s just brilliant.
Finally, the thing we’re really proud of is that our offer was clear to everyone.
We gathered a lot of feedback (also from people we rejected) and almost everyone agrees that everything they needed in order to apply or accept our offer was explained. There was no unnecessary mystery involved.
Summary
So far, our internship program has gone very smoothly. We learned a few important things when recruiting interns for the first time and we’ll be able to improve these things next summer.
We’ve just finished the internships, so we’ll be back with another assessment of our findings in the middle of October.
Author: Rafał Cymerys
