How to Avoid Badmouthing Previous Employers in Interviews

A friend who is getting started in their tech career asked an important question about navigating interviews. I ended up giving them some extended advice that I wanted to share here.

Question: What’s y’all’s advice for speaking positively in an interview about a job you feel negatively about? In general, how do you balance being honest with not coming off as a negative person in interviews?

My Answers:

Here's my advice as a hiring manager. YMMV.

Unless they explicitly ask about the negative stuff, don't volunteer it. It's perfectly fine to not bash previous employers.

Talk about what you learned. Either technical or otherwise. You can talk about difficult projects and why they were difficult. If it's because some people on the project were causing problems, either talk about how you tried to help, or just don't mention that part.

Talk about the product or service. Talk about why it's useful to customers/clients. Talk about how something you worked on improved the business in some way. Revenue, customer value, reduced costs, etc.

Some places ask you explicitly why you left a previous job. Don't answer that. Just say they couldn't offer you the kind of growth you were looking for. (Be able to describe the kind of growth you're looking for).

Bonus: A peek into what the questions might actually sound like

I have a go-to question that I ask. I ask people to tell me what kind of environment they have thrived in and one where they have not been able to do their best work. It's a tough question because it seems to point at the negative things. But you can answer that question by talking about yourself and what you need to thrive. It still doesn't require bashing the company or other people.

Interviews are always challenging. Knowing what to say and what not to say only comes with lots of practice. As a final thought for people trying to get hired, I highly recommend that you seek out opportunities to practice interviewing in a low stakes environment. Get used to putting together the words that give interviewers the info they need without inadvertently saying something that paints you in a bad light. I hope this post gives you some helpful guidance to get started. Good luck out there.

A Few Words On Architecting Technical Solutions

I was having a conversation with some other engineers about architecting technical solutions. As is my habit, I ended up talking about some of my personal philosophy.

To me, success is about finding the space between what’s possible and what’s good. And there’s not one objective answer, the right thing is defined by the goals and constraints of the parties involved.

By success I mean that, as an engineer, I want to build a system that everyone is happy with. Everyone being the team, the business and our users. That’s hard to accomplish of course. If it was easy, everybody would be doing it.

The challenge with designing a system for a for-profit business is not just imagining something that seems conceptually possible. It’s about trying to anticipate the cost of building the thing, where cost is ultimately measured in person-hours and calendar time. In my experience in building software, all of the other factors in cost are dwarfed by a couple of things. Is the tech you choose battle-tested, and does the team who is going to build it have enough expertise in that tech.

The 3 Challenges of Influencing Your Team

Recently I had a conversation with a good friend of mine. Rachael Stedman is a great engineer and manager, and we often talk about how to help each other improve. With permission from her, I’m reposting this with very little editing.

rachael: Does this mean you’re still happy as an ic? What kinds of things are you doing / owning as a ic?

polotek: I'm happy with the work I'm doing. There are definitely some frustrations. Most of those I chalk up to a gap in leadership. So I'm working on what it takes to gain that influence as an IC.

rachael: As a manager I’m realizing how meaningful it is to have strong IC leaders to partner with  

polotek: Right now I'm helping to upgrade our frontend. Which also entails making a lot of decisions about standard patterns. And hopefully I can spend time really helping the team level up.  

rachael: That sounds great - how are finding making those kinds of standard decisions - is it hard to get buy in?

polotek: Oh yeah. There's no process. And no real venue for getting the right people to engage with the details. I think we've talked about this before. There are a few stages to trying to get things done. Engagement, decision-making, and adoption of decisions. Each one is difficult.

rachael: Lol I think the most I know about getting alignment I learned from you. And repeating yourself

polotek: The reality is if you really want to push something forward, you have to go around to all the key stakeholders and get them to make time individually.

rachael: Yeah, my new pet peeve is when people use “disagree and commit” to push things through without actually getting alignment. I like the breakdown: engagement, decision-making, adoption. Interesting word choice: engagement. Engage each stakeholder? Engage with criteria? Engage with... data? Other things?

polotek: Yeah. It's probably over-used. But it comes from a place of accepting that people aren't always paying attention to you. You won't get what you need out of them until you get them to actually pay attention.

A lot of times I see people put something out there, in a document or a slack message or whatever, and they're confused about why it didn't result in any feedback or activity. The reality is that unless you help people understand why it's important, they may filter it out of their attention and expect someone else to deal with it. Because we're all busy, we're all constantly doing that filtering. So you can't just put something out there, you have to get people to engage with the conversation you're trying to have. Engagement.

rachael: Oooh well said