00:00:04.210
Our next speaker is Ivan Nemytchenko. He's from Russia, but right now he is living in Serbia. He has been a Ruby enthusiast since 2006 and a speaker since 2010. He has led something at GitLab since 2016. A little bird told me that he wants to brew 50 liters of mulled wine for an after-party. What's the story? So, let's welcome him on stage and enjoy!
00:00:47.899
Thank you. That's true. Today, I'll be talking about my experience of organizing a remote internship for junior Ruby developers. This happened a year ago, so this is not related to my work at GitLab. Instead, I spent time actually exploring development and its possibilities and explaining it to other people.
00:01:07.729
I spent almost two months exploring the possibilities of GitHub Continuous Integration, and I have a question for you: please raise your hands if you're using CI systems. Thank you! It’s actually hard to understand who is and who isn't using CI, so yeah, I know that's a shame. But let's get started!
00:01:51.350
I got my first paid job as a programmer in 2002. I switched to Ruby in 2006, and by 2008 my projects had grown larger. I found another person with similar experience, and we started to work together on a project. This context is important for the story I’ll share.
00:02:29.310
Later, we found two juniors and taught them everything we knew. We started to work together. Eventually, our small company was merged into a startup, and one day two students appeared in our office. They needed a project to finish for university and needed documentation proving they completed a project at a real company.
00:03:00.959
We gave them tasks, they completed them, and we provided them with the necessary paperwork. They then disappeared, but later, they graduated from university and came back to me, expressing their love for Ruby. They wanted me to continue teaching them and help them become Ruby on Rails developers.
00:03:31.799
Since I had been working at a startup, I had learned quite a bit about how startups function. I had many ideas I wanted to develop, and I saw it as a good opportunity to pass some of my ideas to these juniors for implementation while I taught them how to build Ruby on Rails applications.
00:04:01.650
Two months later, they built a prototype for me. I presented my startup at some meetups. However, I realized that building a prototype and writing code is not enough to become a real startup. Later, I joined another company where those two guys also became developers.
00:04:41.590
I eventually quit that job and returned to freelancing. It was during this time that I realized I had missed out on a lot of learning. My code quality was subpar; my business logic was tightly coupled with the framework. I began reading extensively, watching videos from conferences on topics like SOLID principles, design patterns, and architecture.
00:05:21.250
I had a couple of projects where I applied newfound knowledge, and I even gave talks, like 'Stop Being a Rails Developer' and 'From Rails Way to Modular Architecture.' I created a website called railsfarce.com. The first lesson I want to share is this: don't be the best student in your class. If you're the best student without a mentor providing feedback, you might spend a long time trying to improve.
00:05:58.720
Now, let me tell you about the internship, which happened almost exactly a year ago. I was working part-time on a freelance project and looking for ways to invest my spare time in something interesting and potentially useful. I wanted to find a couple of developers to create prototypes for my applications while teaching them at the same time.
00:06:55.160
What they would gain from the internship is important: they would have a project to add to their portfolio, experience developing from idea to production, and insights into teamwork and remote work. The technology stacks were kept simple, mainly focused on Ruby on Rails, and I requested a commitment of at least 20 hours per week.
00:07:43.110
I wrote a blog post about this, which accidentally became very popular. In the first couple of days, I received about 20 applications, and within a week, around 40 applications. Initially, I was excited that the internship was gaining traction, but soon I became overwhelmed by the volume of applicants.
00:08:28.200
I decided I would need to filter the applicants, so I started to think of tests to sort through the candidates. While working on this, I received approximately 60 applications. This led me to another idea: perhaps there was enough demand that I could turn the internship into something scalable.
00:09:01.920
Instead of rejecting anyone outright, I made the aptitude test. If applicants could finish it, they could work on a project. Let me show you how the test was structured. The first part was straightforward; they needed to create a simple web application that included registration, a product list, and the ability to create and view products.
00:10:13.800
Most interns could accomplish this in a day or two. After someone completed the first part, I would send them the second part, which included more complex requirements, including handling three different types of users, each with unique registration forms and validation rules.
00:10:53.220
For the third part, I introduced the ability to purchase a product via an external API. The logic for this purchase was somewhat complicated—if done naively, the code would be laden with nested if statements. I did no code reviews between stages.
00:11:21.250
The end result was intentionally poor code, as I wanted the interns to write the worst code they could manage. My intention was to prompt them to think critically about their decisions. Different approaches to user types could arise—like single table inheritance (STI) or multiple models.
00:12:05.069
My goal was to make them aware of the challenges that come from their decisions. Ultimately, they experienced not only the mistakes but also the consequent pains of poorly structured code. I observed common mistakes, like ignoring abstraction levels or conflating external API handling with business logic.
00:12:53.540
After this test, I organized Hangout calls to review the code of the first batch of interns that completed the tasks. We went through every project step, analyzing the decisions made, discussing what was good or bad about each choice.
00:13:15.690
I then delivered short lectures about patterns that could help solve many of the issues they faced. Following that, we had a refactoring session, where they worked on each other's code, and afterwards we progressed to the project phase.
00:14:23.430
One of the first successful projects was the Ruby on Rails quiz, completed quickly by one of the teams, and it gained traction. Another exciting project was that the interns developed the platform for the internship themselves, including automating task delivery.
00:14:52.620
Whenever someone created a tag in a repository, they would receive the next task automatically, and another team implemented a dashboard for easy project and tag browsing. One of the most ambitious projects was intended as a standalone open-source alternative to New Relic.
00:15:27.290
The project was led by interns with two external mentors, myself included. This project was ambitious and indeed challenging for the interns. I also faced logistical issues; with around 16 interns eager to work on projects, I only had those two mentors for guidance, which placed a heavier load on the remaining mentors.
00:16:10.870
I realized that I was treating the internship as less significant than it actually was. While I had anticipated a straightforward project, the reality was complicated due to the inexperience of some junior developers. I found myself playing three roles: product owner, project manager, and code mentor, which eventually led to burnout.
00:17:06.720
Moving forward, I wish to filter applicants better and manage the expectations more realistically. Even with only two teams, managing those teams was challenging. Having two more could help mitigate some of the management issues encountered during the internship.
00:17:53.860
The aptitude test was a resounding success in terms of allowing interns to understand what they needed to improve upon. I received emails from those who passed the test stating that they were able to find good jobs as a result. Reflecting on this year, I would consider running a similar program again.
00:18:41.600
Now, let’s discuss the needs of junior developers. Primarily, they need authentic projects to work on. A real project provides context, with an underlying business reason for tasks—this is critical for development.
00:19:39.130
Additionally, they need projects that they can showcase in their portfolio, experiences that cover the entire development cycle, and the opportunity to work as part of a team. Many beginners lack these collaborative experiences.
00:20:19.370
Learning can take place at conferences, which can be a gap for developers in transition. I call this exploratory learning. You expose yourself to a variety of new skills and information, asking yourself where to direct your efforts.
00:21:01.550
If you dedicate time to focus on one skill, you can improve in that area, but you may lose sight of others. While reading books or taking online courses can build a solid understanding of theory, practical application often requires hands-on experience and feedback.
00:22:03.490
Beginners often undertake pet projects, which develop practical skills. However, without mentorship and feedback, they may miss out significantly on crucial constructive criticism necessary for growth.
00:22:52.150
Many beginners mistakenly believe that reading books and watching courses will automatically qualify them for positions, ideally when they have absorbed enough information. In reality, effective learning is incremental; starting with something practical yields better opportunities.
00:23:38.750
By growing from simple tasks such as scraping web pages, beginners can improve gradually, making themselves increasingly valuable. They can also contribute to open-source projects, where they engage with like-minded developers in meaningful, impactful ways.
00:24:35.160
Senior developers often find themselves busy with numerous tasks—research, routine features, and missing functionality in open-source projects. They often lack time to contribute to the very projects they wish to see improved.
00:25:44.080
However, these responsibilities align precisely with the needs of junior developers. If seniors delegate certain tasks to juniors, they can help foster a collaborative environment where everyone learns and grows.
00:26:42.720
The ideal situation would involve juniors sharing the senior mindset, cultivating growth and responsibility. This mindset is formed through individual project experiences and learning from mistakes made at various stages.
00:27:55.230
I propose turning this experience into a set of well-defined tasks for juniors, mirroring the tasks seen in the initial internships. This could be beneficial for companies that could leverage this collaborative synergy, orchestrating skill development and project results.
00:29:01.750
If I decide to run this internship again, I will implement better testing methods to assess candidates, not only for juniors but also for mentors. I plan to clarify the guidelines that mentors need to follow and to continue creating tasks that channel valuable mentor experiences into developmental opportunities for the interns.
00:30:30.780
Thank you for your time. I still have some stickers left, so please come and ask for them. I'd love to engage with anyone related to teaching or mentoring newcomers in technology.
00:31:05.750
Thank you!
