Secrets of an Engineering Manager with ClassDojo

QUESTION 1: Tell us about your career. Were you always in tech? How do you feel looking back?

I’ve always been in tech (almost 20 years). It’s been the right choice for me for sure — it’s more of a lifestyle than a job for me. I’ve been writing software for fun since I was around 7 years old. I got a little bit heavier into the practice and process side of engineering about 10 years ago when I realized it has an immense impact on productivity and well-being.

QUESTION 2: What are the hallmarks of a quality software engineer?

The best way to level up as an engineer is to consistently demonstrate being effective (You don’t get points in life for effort). Think far and wide about the effects that you’re responsible for and don’t stop until you’ve achieved them. This is actually super-rare. Ask 10 engineers what they do before they tell people their software is done, and very few will tell you anything that shows real ownership like “When the users love it”. Even fewer can tell you what measures they take to ensure that happens.

QUESTION 3: What is your gut instinct about the future demand for software engineers (up/down/same, long term/short term)?

Given that, would you start a transition into software engineering today?

Software is eating the world, and the last people to lose their jobs in the impending robo-pocolypse will be programmers. As a 40-something I’m a bit concerned about ageism but if it’s a thing, it hasn’t affected me yet.

QUESTION 4: How do you hire to ensure great teammates? Is it working? Would you advise others to do it? Is the same or different for bootcamp graduates?

Our interview process was/is designed iteratively by the entire team, and the 5 or so 1-hour stages of it (including a team fit interview) usually involve most of the team as interviewers. The team decides on the candidate as a group in the post-interview meeting. Our current engineers are completely bought into the entire process and into making the new candidates that they approve successful. This process works so much better than anything else I’ve seen that I now consider it a best practice.

For bootcamp graduates (and juniors in general) we relax some of the interviews. The team-fit interview is limited because they have no real team experience to inquire about. We usually don’t expect much from our lower-level systems interview either, because bootcamp curriculum doesn’t cover it. We’ve also got connections to the bootcamps that we hire from and try to ensure in advance that we’re getting candidates that are near the tops of their classes. I realize this is cheating.

I think on-boarding is a pretty critical aspect of hiring too. There’s a terrible practice of giving a new hire a laptop and a cubicle and saying “good luck!”. It’s just such a huge waste of time for the company and source of anxiety for the developer. The new team should be hand-holding as much as necessary to get this new developer actually productive despite all the new company practices/processes/tech that even an experienced developer would have to learn. For this reason, we almost always pair program and get something into production on the first day. You ensure good teammates by being good teammates.

QUESTION 5: One word of advice to first-time engineers (CS, EE, engineers, self-taught, etc.)?

Nearly everything in engineering is a trade-off. Learn both sides of the trade-off in every technical design or decision if you want to start making good technical decisions yourself. Every time you learn a new piece of technology think about the trade-offs. This is a long-term skill that will outlast any technology-of-the-week and always keep you relevant. You’ll start to see that there’s a lot of irrelevant pop culture around technology choices that you need to ignore if you want to be truly innovative and effective.

I’d also like to add: Make sure you like it! It’s a commitment to continuous learning, so if you don’t like it, you’re in for a real slog. If you do though, it’s amazingly rewarding.