One of my fellow Recursers is actively researching needs of newbie developers and interviewing juniors, mentors and anyone else engaged in hiring programmers who are starting out. Given my experience so far, I more than qualified for an interview as a tech industry newbie.

At first I thought I wouldn’t have any relevant insights, since my experience is very fresh and I haven’t encountered any of the serious problems many face in tech. I started talking and only realized about 45 minutes later that our chat is nearly over.

First developer job - no mentoring

The team I worked with in my first development job was not experienced in software development. They were, just like me, mostly economists who learned to program, without any previous experience in building applications. Even though they’ve done thorough research and managed to build a pretty good product, I was constantly struggling.

I didn’t have an experienced developer as a mentor, so I felt I was learning only through making mistakes. It’s not wrong to make mistakes and fix them, but it can’t be the only learning strategy for effective development. The job was more about quick fixes and tiny new features than important contributions that enhanced the core product. I was barely taken into account when building important features, usually as a person who’d work on implementation rather than an equal contributor.

I didn’t have the words to name most of my concerns. I felt that no one cared about my growth as a developer and an employee, even if that could be beneficial for the company in the long term. Most of the time I wasn’t sure I was doing things right and had serious doubts if I was even working on the right things.

I felt that I was the only person who had these problems. How could I pinpoint such vague ideas like “you are interrupting my learning process” and “I don’t think this solution is something we want to do, since it’s not best practice”, especially when I didn’t know how the process should look like or what are the best practices?

Recognizing bad mentoring

I was very lucky to spend three months at the Recurse Center, where I was encouraged to ask questions and voice my concerns. The concerns were taken seriously, even if I felt I’m being overly sensitive. That helped me recognize bad mentoring, among other behaviors I couldn’t previously name.

I’m not saying any of my mentors intended not to help me or were driven by the wrong things. Bad mentoring is not about intent, but the way of approaching a problem. Mentoring should be about helping the mentee with their problem at hand, in a way that helps them grow and encourages them to try and learn. It’s a skill to be learned.

Bad mentors ask questions they already know the answers to and get impatient when they don’t receive the right answer quickly. They sometimes answer their own questions to speed up the process and correct the details before making sure the mentee even understands the problem. They say something is “obvious” or “easy”, which further discourages the mentee from trying.

Bad mentors answer the problem they see, not the one the mentee asked to be helped with. They focus on their comfort and the right approach instead of focusing on the mentee’s learning process. They sometimes don’t even try to help with the actual problem, but rephrase the issue to answer something that’s more interesting or easier for them to explain.

Bad mentors don’t give the mentee time to find answers on their own and explore. They don’t want to explore with the mentee. They throw resources at the mentee and don’t set up a feedback loop that would encourage them to communicate.

I think bad mentors in tech are often experienced and skilled developers who forgot how hard it was to get to where they are and didn’t think to ask.

Building a relationship with a mentor

One of my best friends at the Recurse Center was also my first great mentor. Over the course of our batch we developed a relationship based on trust and mutual respect, motivating each other to grow. I still think I got more out of this dynamic, even though I’ve been a mentor myself for the past few weeks and I know how much I’ve learned from that.

My first great mentor expected me to not give up on my problems and approach them with a curious mind, instead of stressing out and feeling inadequate. He expected me to first try and answer my own questions, even if I was worried I’d get them completely wrong. He’d discuss features with me and make sure I understand what’s happening, addressing relevant parts of my input.

Whenever I got lost, I could just ask him, even if it felt like the stupidest question ever. The fear of embarrassing myself gradually went away thanks to all the confidence he had in me. After a few weeks, it felt more like a partnership of equals than mentoring, even though there was a vast difference in our knowledge and experience.

Working with open-source mentors

When I started working with Zulip I didn’t know any of my soon to be mentors. They could only learn about me from chat and my contributions, without having the opportunity to get to know me in person, which could help me be more confident. I’ve been entering this community of awesome developers and all of them knew much more than I did - how could I possibly bring value?

I was lucky again since Zulip maintainers and contributors are not only welcoming to newbie developers, but also have experience with introducing them to the project. Zulip has great documentation and the team is very responsive on chat.

When working on a feature, mentors would set up a context for my work, providing any relevant information and making sure I understand the problem well. They’d answer my questions and encourage me to share work-in-progress code to drive the conversation.

From day one I was treated like a contributor, a partner, not a problem. I was taken seriously and expected to be a responsible community member. My input was valued and taken into account, my questions answered. I was also constantly encouraged with gradual code reviews that improved my skills and workflow tremendously over the span of a month (and are still improving).

Dealing with the real world

A newbie developer and a woman, I’m sure to face some communication issues in my future endeavors. I will have to prove my abilities and substantiate my reasoning. That’s why I also seek out more direct and less welcoming mentors, who will compare my solutions to optimal ones and not make it any easier for me to solve problems.

It’s not easy to deal with direct questions about my implementation and go into the nitty-gritty of my code without the comfort of additional research and asynchronous communication. I do however need to know my stuff cold if I want to become a better developer, so I welcome mentors who are harder to deal with.

What’s important to the mentee

  • Believing in them.

    It’s not only about supporting the mentee, but also challenging them and giving them real responsibilities from the very start. Building a relationship based on trust requires accountability and a good way to motivate oneself to deliver is knowing someone needs our input.

  • Being excited about their growth.

    Every review at Zulip begins and ends with a positive note. Start with a thank you when the mentee is asking for a review - they are learning and a great way to learn is to build and improve.

  • Setting up a learning environment.

    Give the mentee context for their work - point them to other contributions and relevant docs. Treat code reviews as learning opportunities and give incremental steps to improve the mentee’s work, starting from the core functionality and expecting more and more self-guidance and quality.

  • Encouraging them to leave their comfort zone.

    Ask the mentee to read others’ code, support them in mentoring less experienced contributors. Push them to share their code early with work-in-progress pull requests - I for one had to talk myself out of being this perfect person, who should never share their mistakes.

  • Introducing different kinds of mentors.

    Encourage the mentee to ask multiple mentors for advice and help. Let them learn how to communicate with other team members and benefit from their guidance.

  • Balancing the amount of information.

    Don’t give the mentee answers right away, but don’t leave them hanging for too long. Start with not giving enough and gradually find a balance with providing more details while expecting more self-guidance. Stop before you answer your own questions.