As a Principal Developer, Brad has experience in the planning and processes behind architecting bigger solutions at Mappedin while also being hands-on with coding, building features, and maintaining services. Today we discuss his role, provide thoughts on what makes a successful developer, and share tips on how to nail a developer interview!
I'm a Principal Developer, and I focus on the big picture of the software architecture at Mappedin. I’m regularly thinking about the way that our different services communicate with each other, where new features fit in, how certain APIs and other sources should be developed, as well as thinking about the different technologies we might want to investigate. I'm also an active individual contributor. I write a lot of code, build features, and maintain a lot of services.
When I started at Mappedin, there were less than 10 employees. I was put in charge of a fairly large JavaScript project, and at the time I didn’t have much experience in JavaScript. I had to learn really quickly and it’s kind of been the same pace ever since.
I was also a manager for a year, but I realized that it wasn’t really the direction I wanted to take with my career. Mappedin was really supportive in letting me transition into a managerial position, then transition out of it, which was really nice.
I really enjoy the fact that I can be an individual contributor and write code, while also being involved in the planning and processes behind architecting bigger solutions. I’m also afforded the freedom to explore new technologies that can benefit the company, which is really rewarding and offers a lot of creativity.
I really enjoy all the people that I get to work with at Mappedin. I can't say that I’ve had a hard time getting along with anyone that we've hired. It’s a great place to work and there’s plenty of opportunities for growth.
You have to learn fast and be willing to make decisions with only 70% of the information. The amount of experimentation to learn, fail, and build something even better has always been present at Mappedin. You have to be willing to take a certain amount of risk in terms of developing features and trying things out to see if they work.
We're still at that smaller size where you'll get a lot of say in how things run. Working at a much larger company you could become a cog in the machine, but at Mappedin you get to be the one building the machine and dictating the direction that it goes.
Fun fact — we don’t ask complicated leet code questions. We have a question to confirm that you can write some for loops and work your way through a problem, but the actual solution should be simple. Understanding the problem and asking questions is important, because the solution to the problem is fairly straightforward, but what’s difficult is understanding what the customer wants.
Then we have a system design problem that is similar. It’s about coming up with the simplest, most straightforward solution, as well as trying to figure out what the customer is looking for or what us as developers are looking for.
Most of our successful candidates have gone to the effort of writing something that maybe doesn’t work, keeps on asking questions to try to figure out why it doesn’t work, then gets a working solution. An unsuccessful candidate usually doesn’t ask many questions, tries to go it alone, and then gets really stuck.
Interested in working with us? Check out our Careers Page for all open roles, including the Senior Backend Developer role, or send an email to our recruitment team at careers@mappedin.ca.
Paul is Mappedin’s Director of Engineering. We’re discussing his journey at Mappedin, some cool things the Engineering team is working on, and the hiring process for a software developer. Paul,...
Culture
Article