This is a transcript of episode 185 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.

A listener asks how to find a great company to work for, and Jeffrey and Squirrel share a few opinionated, biased heuristics for discovering great environments to work in.

Show links:

Listen to the episode on SoundCloud or Apple Podcasts.


Listen to this section at 00:13

Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.

Jeffrey: Hi Squirrel. We got something I really enjoy getting: a question from a listener. A listener named Idan messaged me on Twitter and said ‘maybe you could do an episode about what great companies have in common and how to find one as a software developer who is looking for a new job.’ I thought ‘Wow, that’s a big topic.’ Right off the bat, what are you thinking?

Squirrel: You forwarded this to me a couple of days ago, and I think that’s such a big question we’re going to have to give some disclaimers. So here’s two. The first one is: there’s only so much you can tell from the interview process. I do an awful lot of hiring. I did a calculation a while ago and figured out I’ve interviewed 1,500 developers for developer roles over my many years doing this. So I have some experience doing this and I coach teams and companies in how to do it. I’m perfectly happy to talk about what I think a good hiring process would look like and what you would see as a developer in that good hiring process. But, of course, that may not correlate to a great company. It may be that the company has a great hiring process, but it is actually isn’t great: it’s good at hiring, but not at other things. The other disclaimer, of course, is we’re going to give you a biased answer. We’re going to tell you that, for example, the company should be transparent and curious. If you don’t value those things you might be disappointed. This is going to be a biased answer of what we think a great company would be, and we’re only going to be able to tell you what you can see in the interview process. Even with those limitations we have a lot of ground to cover.

Jeffrey: I felt a little bit exposed in reading this question. Have I ever worked for a great company? What do you think of as being great? I’ve great times and great experiences, when I thought the way we related to one another was great. To me those were very valuable. We perhaps we didn’t always get the greatest commerical outcome. So if a great company means great on every dimension, great relationships between people, great technical practises, great culture of learning, great commercial success, all of this together, I’m not sure I’m qualified to answer. My response is going to be limited by my experience of the things that I have found great and what I have used as a guide to find those opportunities?

Squirrel: Well with those disclaimers maybe we can still try and answer the question. If you’re looking for a company that’s transparent and curious, and that we would be happy with, and you’re willing to judge it based on its interview process, I think we can say something.

Do They Read?

Listen to this section at 03:28

Jeffrey: I remember Alistair Cockburn many years ago talking about visiting someone that he knew at a company in Australia. This person had recently taken over as head of engineering and wanted Alistair to come do an assessment of the team. In Alistair’s telling, after a short time walking around on site he said ‘I don’t think it looks very good.’ Knowing Alastair, he probably worded it a bit stronger than that. His friend was surprised and a bit taken aback. ‘Why do you say that?’ I have to point out the timing here, quickly. This is 90s or early 2000s. So Alastair said, ‘Well, I look around all the developer’s desks and I don’t see any books. If there’s no books, that’s a sign that these people aren’t curious about learning and expanding their skill set. That’s not a good sign.’

Squirrel: Books can be on desks? That must mean Kindles.

Jeffrey: This is back when the stack of books from various publishers might be more prevalent. O’Reilly books, the animal series, all kinds of technical books. These seemed to be a much bigger business when you could see each other’s desks and there were fewer electronic books.

Squirrel: It strikes me that you’re going to have to ask questions, because you may not be in the office, you may be doing it all remotely. Jeffrey and I are doing this podcast bi-continentally, right? Jeffrey is on another continent. So I couldn’t see whether Jeffrey has a book on his desk, but I can ask him ‘What books have you read recently? What books has your team read recently?’ That would be a mind blower. ‘Does your team read books together? What have you learnt recently? What are you investigating?’ We’ll put that on the list of things that you can interview the company about: find out whether they’re curious enough.

Jeffrey: Openness to learning in the company is certainly a key element for me. I can contrast two companies I worked for. In one, the company’s practises, coming from Silicon Valley, were relatively mature in some dimensions, but the company itself was very open to learning and adopting new policies, and that was great. By contrast, I remember working for a company that had a new VP of engineering come in who literally said while introducing himself to the company ‘You can’t learn anything from books.’ I was appalled. This is someone who had a lot of experience and probably knew a lot of things, but it was very clear in my mind that we were going to be limited by their personal experience. They weren’t looking beyond that experience because they had this idea that you can’t learn from other people’s experiences that have been recorded on paper, which is still an astounding mindset to me.

Squirrel: Certainly we wouldn’t have made 180 episodes of this podcast if we didn’t think people could learn from each other’s experiences, so there’s our bias coming in. If you agree with that person, you’re probably not listening! So Alistair’s criterion is, ‘are they reading, are they curious?’ And we have some questions that we can ask them about that. Do you have more?

Jeffrey: Well, the people who I know are curious and have a similar mindset become very valuable pointers to where there’s opportunities of the type I would appreciate. For me personally, I was looking back on how my time with CITCON was such a great way of meeting like-minded people and those with a similar set of values.

Squirrel: You met this guy named after a rodent there? He got you a job, helped you to move to England.

Jeffrey: Exactly. You know, when I joined TIM there were a number of other people who you had met at CITCON who were there as well.

Squirrel: It was a great recruiting ground for me. So on the other side, I was looking at CITCON as a place I could go to find like-minded people who could come work at the company. I found you amongst many others, and that was a great thing. You could do the same on the other side.

Jeffrey: I’ve had some similar experiences at DevOps Days, and more recently, the DevOps Enterprise Summit. It makes sense because conferences are places you can confer with people in your industry, and that’s going to be a good opportunity to find people who are like-minded and develop those relationships and ask them about their own experiences. ‘Do you know of companies who have an approach you value?’ There’s an element here of selection bias, but the key thing is we’re looking for biases we can use in our favour. In general, I’d say the people who share my values about learning and improving tend to be actively out there trying to learn and improve, and therefore that’s how I will find them.

Do They Look for Fit?

Listen to this section at 10:50

Squirrel: So that’s a way of actually identifying the company before you meet the company. I’ve got a couple of things that I can say about how I tell companies to do their interviews. Here’s the first and most important for me: do they ask candidates to do some part of the job? I usd to quote the Joel Test by a blogger named Joel Sapolsky: ‘do people write code in their interview?’ I now would broaden that to say, ‘do candidates do something that is an example of their work in an as realistic situation as possible during their interview process?’ I say that because I don’t know a way to tell whether somebody is a great designer without having them design something. I don’t know a way to tell whether someone is a great product manager unless I say, ‘Hey, can you design this product for me?’ I have some sneaky things that I do to try to get them working and being creative and handle curveballs and surprises. Similarly, I want developers writing code in the interview. Now, there’s something that you’ll find if you go search for ‘whiteboard interviews’ or ‘coding tests’ or something. You’ll find a class of people often on Hacker News who say that’s a terrible thing. They claim their interviews focus on things you might study in a computer science class, memorizing these random algorithms. That is not what I mean. Companies that do that may also be great, but that’s not the discriminating factor for me. What I’m looking for is an experience that is not ‘please go to the whiteboard Jeffrey and do this thing that you’ve never seen before and sweat and look uncomfortable and don’t have any kind of help or integrated development environment or Google or anything and do this completely unnatural thing.’ This is the opposite of what I mean. What I mean is go work with me, ideally on a real computer. I also do it on paper, but I do it with the person and I invite them to ask questions and I help them. It is a pair programming session that I do with the person. The same can be done for a designer or product manager. Or increasingly, I’m helping to hire folks like CTOs and heads of product and there I have a whole process called a reverse interview, where the person engages on a real problem, interviews people in the company and then comes back with their plans, just as they might do in their first week. So those kinds of practical engagements with real problems that are supportive and helpful. If they ask you to do something like that, I think you’re on to something that could be a winner. So that’s one of my two. The other is, are they asking you questions about culture? On the front of our book, it says, ‘transform your conversations, transform your culture.’ If they’re not asking you cultural fit questions, ‘Would you be comfortable phoning a user,’ for example. ‘Would you mind being on the customer support desk for a day?’ They’re filtering for the sort of person that they want to hire. Now I would like to work for a company that wants developers on the customer support calls. You might not. So it might be that their questions help you to determine you’re not a good fit. Great! The questions are working. It may also be that they ask you cultural questions, and most of your answers are yes, that would be a good sign. They’re thinking about culture. They’re interested in creating a positive culture and a defined one. They know what the culture should be and they’re filtering for people like that. That means you’re more likely to find like-minded people. So my two main pieces of advice I give to folks who ask me how to hire are practical engagement and cultural filtering. I think those are things that you could use when you’re looking on the other side of the table.

Jeffrey: I’m reminded a bit of the epilogue of Extreme Programming Explained by Kent Beck, he mentions that all methodologies are based on fear. I know as I’m listening, what resonates with me is the kind of things I would look for to avoid the situations that I fear that I’ve been exposed to in the past. For me, the concerns are places that don’t want to be better, that aren’t open to learning and trying different things. So I would be asking questions to address that fear, like ‘Can you tell me about the times that you learnt from experience?’ But it’s all a function of what I fear and what I believe to be characteristics of great environments, which are ones that focus on learning and those elements. I think in your questions, I hear you’re avoiding problems you’ve seen on development teams that you’ve been brought in to help.

Squirrel: Absolutely. What often happens is you get people who can’t really do the job, either they don’t fit the culture and therefore are not able to function effectively in the organisation that they’re in, or they literally can’t write code or design a new product or interview a user. I can tell you some shocking stories of clients I’ve had where people were just not qualified on either of those axes or both. That’s often when they need my help the most. You want the ones where there’s a focus on culture and where they’re filtering for people who can do the job and they demonstrate learning. I think those would be some good criteria to use. What do you think, Jeffrey?

Jeffrey: I love it. This is one of those times where I’m really keen to hear from our listeners because you and I have laid out what we think our idea of a great environment would be. I’m curious what other people think of when they think of a great company. Would the criteria that we talked about help you identify those great companies? Let us know.

Squirrel: Thanks, Jeffrey.

Jeffrey: Thanks, Squirrel.