How we develop students' potential
The beginning of the journey
I got a job as a developer at the company almost 5 years ago. I worked on a project to manage investments of an oil and gas company. At that time, the workload was inconsistent and the tasks were mostly easy. I asked to load me with another project. After 2-3 months, I realized that I had made a mistake and was not keeping up with both projects, and it was hard to switch.
At that moment, HR gave me a junior and said that he had done an internship with us and that he was cool. That's how I got a padawan (even though I wasn't a Jedi myself). He often handled the project tasks on his own, I only reviewed them. At first, I got involved in complex tasks myself. Then the intern began to solve them on his own. For the padawan, it was growth, for me, it was less routine simple work. Later, I got another padawan in the same way, and that's how I became a master over juniors.
Finding meaning
HR worked on increasing the recognition of our company in universities, and I was looking for opportunities for harmoniously connecting interns and trainees to developers in projects. At that time, I identified several conditions for connecting interns to the team:
The developer must want a padawan, at least not be against it.
The developer must have suitable tasks for the padawan. There are projects in which there are no easy and short tasks, at least at the moment.
The developer must be at least middle level.
Development of the methodology
Gradually, I developed my own scheme for working with interns. After university, any junior will face interviews, so for each position in our company, before the internship, a meeting is held – manager + HR + intern. It is formal in nature. This is how we assess the motivation and possible gaps in students' knowledge, which need to be studied additionally during the internship. At the interview, we ask technical questions to understand what background the potential intern has.
Basic questions: for example, how an abstract class differs from an interface, compiling a small SQL query using 2-3 tables. If a student answers the questions poorly, then I understand that he will spend the entire practice brushing up on this theory. And I will not be able to involve him in the project, the student will not receive practical skills. In this case, we give a list of theory to study, after which he could come to us again.
If everything is fine with the theory, as I call it, then we took on practical training, where the student had to design a web API for the domain area they chose with simple CRUD operations. I checked the database schemes and asked questions and helped with adjustments at this stage in order to distract developers from the projects as little as possible. Most of the students remain at this stage. This is what they manage to do. Only those who want to develop in the profession finish this stage earlier to get into a real team.
How are things in the team?
In a team, an intern or trainee is assigned to a mentor developer, and the developer himself determines what tasks to set. During the internship or training period, the student becomes a full-fledged member of the team. For juniors, this is real experience of working in a team, which is not embarrassing to include in a resume, but for us, it is an opportunity to see how a person will behave in a team.
To Google or Not to Google, That Is the Question
Later I realized that interviews with interns take too much time and I created a regular Google questionnaire, in which I included all the questions that I asked at the interview. Based on the answers, I determined whether to take on an internship or not. I was very afraid to introduce such an approach, because the answers can be googled. It turned out that some students are either too lazy to google or cannot form an answer to the question from what they googled.
I decided for myself: if you answered the question, it's good in any case. The student either knows the answer, or was able to google it, process the information and form an answer, which is also a fairly important skill for a developer. We can say that the process was developed and we have been working on it for about a year and a half without significant changes.
3 Qualities of an Ideal Team Player
Managers often mention in their practice the book by Patrick Lencioni “3 qualities of the ideal team player”. It did not pass me by either, and I began to superimpose the experience of working with students on the model from the book. The model says that a good team player creates value and needs minimal coaching and management. Patrick believes that the ideal team member should be:
Humble – thinks about the common good, not just about himself; team goals are more important than personal goals; focuses on the well-being of the team instead of ego and status; acknowledges the team's achievements; is confident, talks about his skills for the benefit of the team, but does not brag about them. We tested this skill when we connected the student to the team. Students who solved work tasks at the expense of others and took credit for the achievements only for themselves were not tested for this quality (Imagine, this happened)
Hungry – hard working, internally motivated, not a slacker, doesn't need pushing; strives for more, not settles for average; fills gaps in team competencies, thinks about next steps and best ways to achieve team results. It is the desire to do more and faster in stage 2 in order to move to a real team that for me is a sign that a student has this quality.
People smart – wise in dealing with people, understands team dynamics, emotions and motives of others, practices EQ and behaves accordingly, asks good questions and listens, tactfully engages in constructive debate. At this point, I personally try to determine this quality in 1:1 communication.
There can be eight different skill sets in this model. We look for at least two skills to be strong and for the third to not be in the negative. Modest and hungry, but not insightful (communicationally wise) – “Accidental Destroyer” – can achieve impressive results, but ruin relationships in the team with words and actions. Wants good, so accepts corrective feedback. Advice if you are like this: treat everything more positively; listen to others to understand, communicate with people.
Hungry and insightful, but not shy – “The Skilled Politician” is ambitious and hard-working, knows how to show good intentions while looking out for his own benefit. Team members will not see through manipulation right away. Advice if you are like this: try to look out for more than just yourself, say “thank you” more often.
Instead of a conclusion
I recommend reading Lencioni's book about the ideal team player. Apply this model to yourself, see where and what you can change in your work. Changes in work that affect the team's results will definitely not go unnoticed. Conclusion for interns: do more and show in your work a willingness to become better and grow quickly, absorb knowledge and skills from mentors.
The takeaway for mentors: invest in your interns and trainees. Each of you will find your own meaning in this. This includes reducing the typical tasks that you will pass on to your padawan, and, so to speak, paying tribute to those who helped you, and building relationships, because your padawan can help in the future.
