In my previous article I talked about getting strong fundamentals and the technical skills you need to land your first engineering job. In this post, with the help of my colleagues, we look at how a mentor can help you and how to take care of yourself when working on a project and looking for a job.

Find a mentor

I have coworkers who have succeeded with and without mentorship. From my experience, there are two valuable things I received from my mentors: industry insights and code reviews. If you’re open to your work being critiqued and have someone who is willing to mentor you, take advantage of that.

Advice from the internet can often be contradicting, low-quality, have unaligned incentives, or otherwise be not applicable to your situation. People are averse to committing time in advance if you ask for dedicated mentorship, so don’t ask them outright to be your mentor unless you know them well enough to know it’ll be okay. Buy them coffee once in a while and chat informally (don’t forget to bring your questions). People are generally very open to helping in that way.

If you can get someone to take a more front-seat role and review your code, that’s valuable to have. Code review is when professionals read your code and catch those mistakes early on. As a newbie developer, it’s difficult to know your own mistakes and catch bad coding practices.

For people who have mentors, here are some tips on how to be a great mentee:

  • Try your best before asking for help. Tell your mentor what you’ve tried, so that your mentor can get a sense of how you think. This approach is more effective since you’ll find out both why what you did wouldn’t work, as well as why you hadn’t thought of the solution.
  • Explain the problem you’re facing clearly. It can be hard to articulate the problem clearly when you’ve just learned the terms. When you explain your problem, remember that your mentor may not have the context. A good question provides just the right amount of context and asking exactly what you don’t understand. Repeated instances of, “I’m not sure why this doesn’t work” followed by a hand wave toward your code is a quick way to lose mentors who may get the impression you’re not interested in learning.
  • Keep an open mind toward feedback. Code reviews sometimes can be intimidating as it’s a critique of something you’ve worked hard on. Mistakes are how you learn, and there will be plenty caught in code reviews. When your good friend suddenly becomes a monster who rips your code to shreds, it isn’t personal. Try to separate the messenger from the message.

What my colleagues said about mentors:

  • Warren: “I did not have a mentor, but I wish I had. Coding with good practices has always been on my mind, and it can be really difficult to learn that on your own.”
  • Josh: “I don’t wish I had a mentor. I’ve always been more self-motivated and tend to not rely on someone else to motivate me. However, if someone does recognize they need help getting motivated, then that’s totally fine and they should seek out a mentor to help with that!”
  • Clement: “I do not officially have a mentor. Mostly, I spent time doing things by myself. Occasionally, I’ll talk about tech with my friends who are in the same field. Some of them are even seniors who are in the industry. Getting advice from them helps me build my resume.”
  • Albert: “Identify mentors early on. It helps having people who’ve been in the same position you are in to count on. They can be helpful when it comes to career advice, interview prep, and new technology. Mentors can be friends, co-workers, friends-of-friends, basically people you meet who you think are brilliant and would want to occasionally or semi-frequently meet up.”
  • B: Unofficial mentors are great too! 😉

Take breaks

Before the excitement, happiness, and satisfaction at the end of your journey, there will be a lot of frustration, confusion, and uncertainty. Here’s a graphic that helped me feel more assured that I wasn’t off course when I felt unsure along the way. It sums up the emotional aspect of self-studying for a career change.


Drive-by Compromise Technique
Image credit: https://www.thinkful.com
For some people, it can be tempting to put in long hours each day, especially when there aren’t set hours like in the classroom or office. The journey can be long and giving it 100% each day for over a year can lead to burnout or becoming discouraged. My advice is to find a balance. Focus and work hard to minimize the time you’re unemployed, but also take breaks when you need to. The success stories you read can form a survivor’s bias that everyone succeeds. The ones who burn out usually don’t publicize it.

To manage the pressure, I picked up meditation through Headspace, an app that made it easy for beginners like me to get started. I also engaged with some online communities like Reddit’s “learnprogramming” group. I also loved the app “Forest”, which let me set a timer, during which, if I worked the entire time, a virtual tree sprang up; otherwise, a tree got chopped down! That was a fun way to gamify focus for me. Find what works for you and build some habits that will help sustain your journey.

What my colleagues suggest:

  • Warren: “I did my best to stay optimistic during my journey to find my first software engineering job. I knew if I put time and effort every day toward my studies/projects, I’d eventually be a strong candidate for a company that would give me an opportunity.”
  • Josh: “Any time I would feel frustrated, I made sure to take a break and do something fun to distract myself. Disappointment, on the other hand, is a very important part of the process. I left many interviews feeling confident that I nailed it, only to find out that I didn’t. But each and every time that happened, I just made sure to use it as an opportunity to learn and grow into a better developer.”
  • Clement: “My advice is if you are stuck on something for too long, take a break and rest. Do something else to relax your mind. Go back to the project when you are fully relaxed. You’ll eventually find a way. By constantly trying—and failing—you will be able to learn more and grow from the experience.”

Bonus section: more free advice

I hope this article was helpful for you. I’ll wrap up with these great nuggets of advice from my colleagues that would have helped me when I started learning to become an engineer.

Warren says, “I like to think that if getting your first developer position is a progress bar, then every concept learned or code written will increase your progress. As you continue to study and write more code, that progress bar will eventually hit 100%, and you have achieved your goal!”

For Albert, it’s about your network and your approach, “Learn through osmosis: Surrounding yourself with smart engineers tends to help you become a better engineer. Build your network by working with smart engineers at hackathons or meetups and you’ll start to notice best practices, useful tricks, and other things that may help you grow as an engineer. Internships are also highly encouraged because you learn a ton from them.

“Be nice to recruiters: It’s easy to think of recruiters as the gatekeeper between you and the job you want, but if you get to a point where you’re talking to the recruiter, remember, they want to hire you just as badly as you want to be hired.”

Software Engineer

More like this

If you’d like to see more content like this, subscribe to the Exabeam Blog

Subscribe