Thoughts on dev hiring and skill sets : Part 4 Don't work for just anyone
| Product | Culture | Code | Hiring | Career | Intermediate |
How do I know this company doesn’t suck?
Perhaps you’ve looked at their glassdoor reviews, seen them in INC top 500 companies, or a slew of other places saying how wonderful they are - until you step in the door and find out ...it isn’t. Joining a team is different than joinig a company. There are great teams inside of many organizations, just as well as terrible ones. So how do I figure out, or at least hedge my bets, when looking to join a new team?
We've talked about the hiring side in parts 1-3, but now let's hit on the question that will dictate if I should be there - does this company actually suck?
What I look for is 3 things, Product, Culture and Code - it's also why I put it in my company's logo. It's that important.
- Product : what are they building, why are they building it and what/who for, how are they getting better?
- Culture : is it collaborative, innovative, iterative, appropriate, all those good things.
- Code : the core, the lifeblood of the company. Is it treated as such and how well has it been maintained and looked after?
Here’s a few questions I ask when I’m trying to vet a company team. I’ll also give a “why do I ask this” to dig a little deeper. Even if you choose to completely ignore the questions I have laid out, I cannot recommend enough to ask open ended questions around team, product, culture and code. It’s my chance to ask real questions, so I have some ready, well before I go in.
Take a look around
No discussion is needed for this one. When you walk in, what’s the feeling? Is it everyone focused, heads down or is a large number of people talking, interacting -- and it doesn’t really matter about what. When I walk into a place, I want to see a roar coming from product. It lets me know there's some level of collaboration happening. If they're louder than the marketing group, even better.
How do you measure quality?
I don’t mean “zero defects” or “no support calls”, I mean how do they hold everyone to a level of quality and consistency. What practices and patterns do they have in place? How do they follow them, why do they follow them and how did they get there?
This question should shed light on how they handle “QA” and the process of getting things to production. Red flags for me are vanity metrics such as all tests pass.
When was the last experiment you ran? What were the outcomes?
Expect a discussion of how they work in a creative space. When I hear about how they tried x, y and z being glorious, nearly embarrassing failures, this tells me their leadership team is providing a net. It’s ok to try, fail, learn.
On the contrary, if every single experiment turns out to be a wonderful success, or it isn’t a practice of any kind, I see this is a red flag. Typically, somewhere else is using this as a performance measurement incorrectly. Setting up experiments should be the norm, have a pretty high failure rate and not be a mechanism for confirmation bias. The outcomes from them may not have been what they expected (even better in my book) but should not fall neatly into expectations.
How long does it take for an idea to get into production?
Product, Culture, Code
Insight into the level of automation and flexibility. High performing groups its hours - and they do exist. Also embedded into this question is “what makes it in production and what doesn’t?” Sometimes a thing isn’t ready, how does it get the golden go button to head to production? Is there some kind of approval / sign off / audit process?
If it takes a very long time or they don’t have an idea, no es bueno.
How does this group measure success?
I love hearing a combination of the team is happy, customer verification they like what was done and company recognition. It’s often groups, even internal code groups get lost in the shuffle - good organizations realize this, as well.
How do you handle product/culture/code problems?
When everything is going good, everyone's happy and some problems aren't so bad -- winning solves a lot of problems. When everyone's losing, how does that change the picture? I ask what happens when things DO go wrong and how that's handled. This gives me hints to their culture and how are they curate it -- and is it just words on the wall. It doesn't matter where it happens in the stack, it's critical for me to know how bad things are addressed.
Words. mean. things. I’ve found in some companies they have their own meaning for something that, outside of the walls of said company, means something completely, utterly different. These scare me, and shows a lack of understanding and knowledge searching.
I also play close attention to how they talk about other people. Do they call them "resources"? When they talk about someone not in the room is it all factual or do they include a bit more -- "Dave's the go to guy when the band plays, he's our lead singer" for instance.
Wrapping all this up
Thanks for reading my 4 part series. As I've had to put my thoughts down, I've realized its way more daunting than anyone gives it credit. If you're on either end of this -- hiring or interviewing (maybe both!?) I hope you find some of this useful and actionable. If not, hit me up on the contact thing below!