Recently, there was a flurry of activity around one of Brandon's posts about defining the term "senior developer". But he left the purely technical aspects of the role for later discussion, which left a lot of lingering questions.
In this episode, Charles and Brandon dive into the technical side of identifying, hiring, and growing senior developers, and explain The Frontside's somewhat unconventional standards.
Links:
Transcript:
CHARLES: Hello everybody and welcome to the Frontside Podcast, Episode 41. I am your host, Charles Lowell. With me is our other host, Brandon Hays.
BRANDON: Hi, welcome back. It's been too long. It's been one week since you looked at me.
CHARLES: And we were actually talking right before the start off that we don't have any witty banter prepared for this episode.
BRANDON: Also, you just drop that hot Barenaked Ladies reference right on the floor, like an apple pie upside down.
CHARLES: Right, you got to prep me for that.
BRANDON: You're like, "Nope. Pass."
[Laughter]
CHARLES: Like I said, you got to prep me for that.
BRANDON: "In Second 7, I'm going to drop a Barenaked Ladies reference." I'm going to send you three or four music videos. I did send you one that you didn't have time to watch about don't use animal names as an insult. When you say, you're not going to be able to riff off me on that one just yet either, but yeah, I respect you and I respect dogs so don't use dog as an insult.
[Laughter]
CHARLES: Is that 'They Might Be Giants'?
BRANDON: It is not They Might Be Giants. It is three vegan randoes on YouTube.
CHARLES: Is that the name of the band or is that just the content of the band?
BRANDON: No, they're just three vegan randoes on YouTube.
CHARLES: Okay, three vegan randoes is a pretty good band name.
BRANDON: You'll immediately know they're from Portland so you could really pick a lot out of that from just the name of the band. We want to tight 30 today. We don't let people behind the curtain very much, Charles, where people don’t see what it is that you and I do behind the scenes. But one of those things that we do is sometimes we will record a podcast and throw it in the garbage because we hate it, and this is actually one of them. You and I sat down and recorded this podcast before. Just like the hot apple pie Barenaked Ladies reference that I served you earlier, we just dumped it right in the garbage.
We did not like the way that it tasted. We did not like its Barenaked Ladies references, and so this is our second attempt at this. Then the topic that we want to cover today is really important to us to not screw this up. So hopefully, we put a little more effort into preparing for this and thinking very deeply about this.
The idea is that we want to understand from a technical perspective largely what it is that a senior developer is, what they do, how we can find them, how we sometimes miss that, and basically how we define a senior developer so that we can build that as a track for our people to grow toward and find the ones that want to come work with us and may self-identify a senior, how we can kind of verify that. That's the poorly defined topic in our industry, interestingly enough.
CHARLES: Strange, because everybody seems to want that.
BRANDON: Yeah, right. Everybody put it on their job descriptions. Anyway, I wrote a blog post about it. It did all the things that blog posts do when they sort of struck a nerve with the tech industry and they got posted around. I got called literal human feces on Reddit.
CHARLES: Did they call you human feces or do they call you literal human feces?
BRANDON: They said literal --
CHARLES: Did you literally get called literally human feces?
BRANDON: I literally got called literal human feces.
[Laughter]
CHARLES: I shall wear it as a badge of honor.
BRANDON: I was kind of like Ron Burgundy. I'm like, "I'm not even mad, I'm just impressed."
[Laughter]
CHARLES: People had some strong, strong, strong feelings about that.
BRANDON: They did. So now, a skull in a cowboy hat and literal human feces are going to sit here and preach to you about what we think and how we're basically like willing to sink or basically, sink or swim for our business on this definition of senior developer because that actually is core to what it is that we're doing. I want to tee this up and then I'm going to let you just freakin' roll.
I want to provide a little background. The cool thing is, I already wrote a blog post so I don't have to sit here and talk at your face about these things. I was going to tell you some additional thought I've had about this. But basically, the point of this blog post was that we generally categorize what it is to be senior developer in three broad categories that have a little bit of overlap.
The three categories are technical skill, which is the one that people typically think about, evaluate for leadership and connectedness, which sounds all [inaudible] but the reality is it's actually very concrete and very important. The categories [inaudible] leadership is basically the idea that the more ownership you give someone over the broadest version of the problem you're trying to get them to solve, the better they perform.
So if you give somebody a small task, they will maybe perform it. But if you give somebody ownership of the actual problem and the business problem that you're trying to solve or a user's pain point, they will find ways to solve that problem that you wouldn't have considered yourself. They will pull other people into their orbit to solve that thing. Basically, there's a sense of ownership and the experience they have in owning something all the way through to completion basically.
Then, the technical skill one which we'll dive into in this podcast, that's what I want you to kind of drive the conversation around, is basically the idea that the more difficult a problem you hand somebody, the better they perform. A lot of times, that's due to experience, some of it is personality type, some of it is muscles that they like to exercise.
Then, the last one is connectedness, which sounds like it's hard to define but it's actually the idea that the more people that are impacted and the more deeply people are impacted by somebody's participation in a task, the better that person performs. These people like to mentor, they like to be parts of communities, and they have a deep sense of empathy for the users that they build software for and the other developers that they're developing for alongside.
CHARLES: Right, and I think that one of the reasons you got such a negative reaction, you kind of, I think, were assuming technical skill and then really kind of unpacking the leadership and the connectedness as absolutely key components to be what we consider a senior developer. So, kind of pointing out that especially from the leadership aspect, it's like you need to be a wholly-formed developer, you need to have those headlights on the car to see where it is that you're going and you can have a huge engine and like four-wheel drive and like big mud tires that can dig into any surface. But unless, you can actually see where you're going and perceive the problem holistically, those skills aren't going to be put to as good of a use.
BRANDON: I think that's a good metaphor. The idea is that it's traction and direction in addition to the raw technical horsepower that you bring to the table. So pointing out and emphasizing these other areas, I think, made people - there was a lot of confusion. Some people reacted very positively to it like, "Oh my gosh, finally somebody understands that I bring more to the table than just my raw technical capability," especially people from --
CHARLES: I'm going to guess those were the people not in the literal human feces camp.
BRANDON: Well, I didn't set up a Twitter poll or anything but I hope I can assume so. Then there were people that felt very strongly that I was overlooking technical skill. I was like, "No, no, no. That's a fair question. That's Charles's job here." And so that's why, at this point, I am going to drop kick this entire conversation into your side of the metaphorical foot game ball field. I think, football pitch. Pitch, right? Quidditch pitch. I'm going to drop kick the Quaffle into your side of the Quidditch pitch.
CHARLES: Okay, all right. Well, let's unpack the technical skills that we look for. What we're looking for, I think, on the technical side, and this is going to seem obvious but what we're looking for is experience. We’re looking for the quantity of experience and the quality of experience. We can roughly subdivide that into four key areas.
First of all, what's the experience that you've developed around your curiosity? Maybe we should go and lay all these out. We look for curiosity. We look for rigor in your technical skill. We look for your ability and history for actually shipping things, and we look for you to be fearless when it comes to taking on new problems and sizing up the problems that you choose to attack.
When we break down those experiences, if you are a curious person, you have been exposed to a lot of different technologies. So we're going to be looking for, you have an opinion on a bunch of different languages, a bunch of frameworks. We're going to want you to have tried a bunch of different things. We don't want you to have knocked your head against a lot of different problems, and then tried a lot of different solutions. That's going to be very indicative of your ability to bring a diversity of solutions to any given problem that you face.
But it's not just the quantity of the experience that you develop. It’s also like the quality. Like how much in the solutions that you develop are you looking to find the whole solution that fits your problem? How willing are you to do A-Grade work where you consider every corner case and you are willing to dedicate the CPU resources to find the best solution.
Finally, what is the scope of problems that you're taking on? We've talked about the difference between quantity and quality of experience. You can make a career banging out WordPress apps. It's a great place to start but if you're doing it --
BRANDON: Or you can do a CRUD over and over again.
CHARLES: Yeah, you could do CRUD over and over again. Like I said, that's a great place to start at the beginning of your career. But if 20 years on, that's what you're still doing, then you're going to have a lot of experience but is it going to be a high-quality experience? Are you actually taking on bigger and bigger problems, and is the scope of the things that you're tackling growing as you move throughout your career?
BRANDON: It's interesting that's actually like fearlessness, that kind of technical fearlessness is actually a skill a person learns to practice. I was a very fearful developer a few years ago because I felt like if I charged into the bramble of a complex and thorny problem, that was going to cut me up and I die. It turns out, no, it just cuts you up real bad then you get back with thicker skin. And eventually you start going to the point where you start learning to tackle, you learn to take on things you don't understand because that’s literally the job.
CHARLES: I think it's important to point out that fearlessness is a skill. It is not a personality trait and it's something that you have to develop and you can actually take on problems that are too big for you at the given time and kind of have to know when it's time to step back from that. I know that's actually something that I even look for, anecdotally is asking a developer, "What are some of your greatest failures? What are the things where you took on way too much than you could chew? How did it make you fall down flat on your face?" Because that is an artifact and evidence that someone is practicing and taking on things that maybe are too big. Sometimes you're going to overshoot the mark.
You know, you don't want to be taking on too little but one of the ways that you're going to do that is by accidentally taking on too much. And so I find that most people who have a senior level of experience have some big failure story. There's a skeleton in their closet of something they did wrong and they know that they can acknowledge that. I don't know. That's certainly how I feel about it.
BRANDON: Yeah, I can agree with that. I guess you're saying you wrap all of those four things together like whether this person is willing to take on difficult problems, whether they actually complete them, whether they do them in a way that displays that they have enough experience to have kind of developed principles about how they approach stuff and whether they are continuously looking for new ways to approach problems.
Like if you combine all of those things together is this like cool technical Voltron that exhibits a directed, focused kind of practice that over the course of 5 to 10 years yields basically a person that you can throw at any kind of technical problem and they will act like, I don't know, like nanobots just destroying that problem from the outside and until the problem doesn't exist anymore. It's thoroughly solved.
CHARLES: Right. And I think that ties you to this propensity to ship. That’s something that we look for. If this is a skill that you have, if you are at a senior level of experience, you will have a set of technical achievements that we can look at, that you have shipped and we can study them.
Fantastically, as a happy coincidence you can see inside those things that a person has shipped. Are they rigorous? Are they curious and how fearless are they? What's the array of technologies? How unique are the solutions? How informed are they by different technologies and what is the scope of problem that you are trying to take on throughout the course of your career?
So, having actual things that you have shipped whether it's products, whether it's libraries, whether it's open source, something like that, you want to be able to look at those and it is important. We don't rest everything on the GitHub. But I think at a senior level, you should have some equivalent that you can point to, public or otherwise.
BRANDON: Yeah, there's some artifact that pops out of that, and if you made a career of 10 years and you come and say, "Hey, I have been doing this 10 years and I'm a very skilled senior developer but I can't show you anything." I understand that people will find themselves in situations like that but that's going to be, I think, the great exception of the rule.
If you really don't have anything to show, it probably means there's some sort of practice, one of these traits that likely could use a little more exercise on that particular muscle, and that you've been leaning on compensatory muscles in other areas. So that's going to ding you in terms of like, how we evaluate somebody as whether they'll sync or not. And we're open to being surprised. Well, I should probably hopefully get to that before we end our podcast.
CHARLES: I'd like to contrast it with what we look in, in a junior developer because it is very, very different. I think we've talked a lot about or there's a big conversation about, does passion matter in evaluating a candidate? I think passion is a word that's kind of fallen by the wayside but talk about maybe a less charged words like just caring deeply about a product or a solution or something like that.
In a senior developer, to be quite honest, passion and caring is something that we expect to be there but it's not something that we look for because it's not something that we need to look for because if they do care about diversity with technologies, if they have this propensity to ship and they're taking on big problems, then that evidence will be there. So we're not looking for passion because it's either there or it's not. That's something that we look for more in a junior developer because we're going to be looking for that enthusiasm in the same way that you kind of track a hurricane. You don't know exactly what path it is but based on the weather patterns and the basic trajectory, you can find out essentially where it's going to end up.
BRANDON: Yeah, I think there's a lot of talk in the industry about how passion, when people talk about looking for passion, what they're basically saying is we are looking to exploit people who are at the top part of their curve. When you look at how the undulations of a person's amount of passion over the course of their career, you have companies only want to clip off the top of that. As soon as you're not passionate anymore, you jettison that person. What we're looking for is somebody who's sort of stabilized that.
So the passion part of it is like, "Oh, that's cool. The passion is in your past or it's in your present." But we understand that that is a sine wave and we're looking for the line in there that says, "Hey, sometimes I care more than I care about other times but the main thing is I produce things."
Otherwise, instead of looking at as a sine wave of passion, you're like trying to exploit it at the top and then going, "Well, this is just going to keep going up and up and up," and you burn people out for that.
Anyway, so it's not something we look for. It doesn't make sense. It's not sustainable and it's actually something that in a senior developer has stabilized enough that you're not going to see it.
CHARLES: We look for, "Hey, here, we build things. So, if you're at the beginning of the career, are you following a path that will lead you to build good things and then at the end we're kind of towards the back half." We are looking at, "Hey, what are the things that you have built that are capable of building?" And that's the extent of it. I don't want to suck all the emotion out of it but the thing is that I want to suck the pressure out of it.
BRANDON: Yeah, and the way that we try to assess that right now is we do this in a full day pairing interview. We do a lot of stuff that leads up to that and hopefully, the ancillary stuff we do around that helps gauge like, "Hey, this person is active in the community in some way, or they try to make contributions to people this way." We do our best to get a sense of the stuff that is not pure technical skill because delivery, it takes longer than a day. So, how well does this person deliver? How well do they work with other people? That stuff is very difficult to suss out in a day but you can generally get a sense of like technical experience capability.
So I kind of want to focus on like during the course of the pairing interview, what it is that you're sussing out? How do you know a person in a pairing interview is exhibiting those technical leadership traits, technical skill traits?
CHARLES: I'll beat this drum again. I'm looking for quantity and quality of experience. It comes down to little things. How comfortable is a person with their tool set and that demonstrates both the experience and you can tell if it's good experience or not. How comfortable are they with the command line? How comfortable are they with Git? Are they taking baby steps with it or they doing large motions in one kind of fell swoop? Like, how effortlessly is the muscle memory there?
Whatever the tool set is, whether you're using iTerm, whether you're using C-shell or bash or whatever editor you're using, I do expect to see a familiarity that can only come through having done it again and again and again and again. So, if you're working with Git, for example, and you're kind of stumbling and stuttering at what commands to run or pausing, when you are parsing the output of a command if there's an error or something didn't go, what that says is either you don't have the experience which is most of the case or that has not been a priority in the experience that you do have. So there's like kind of a difference in the quantity and quality of experience.
Some people move fast. Some people live slow but I want to say continuity that I'm looking for, in the same way that you can play a piano quickly, you can play it slowly but when people are missing notes, you can detect that. That's what I'm looking for, kind of with the tool sets. When someone is moving within a code base, I'm looking for confidence of motion.
I remember an interview that we did recently where we were working in a code base. We're trying to get something running and this developer deleted like two directories at a time that caused like 10 files to be just missing from the code base. Just gone, at the stroke of a key. Then, we ran the test again, and lo and behold, like everything worked. Or the test that we were expecting to fail failed.
BRANDON: Or was that the test directory?
CHARLES: Sorry, what I meant was --
BRANDON: No, I know what you mean. They were comfortable enough in their understanding of the code base they were working in.
CHARLES: Right. There was a high level. We were not down in the weeds. There's like you're applying very light pressure to the code base to make it move in gigantic swings so you understand the pressure points and you can zero right in on it.
BRANDON: You can say you're looking for like, the aikido development strategy or whatever.
CHARLES: Right, and then the other thing is being able to -- and this is important because I don't believe that every coding session or every pairing session needs to be this dance across the keyboard. Certainly there are times when you recognize that it's natural to stop, to pause, and have a discussion and say, "Wait a second. What are we doing here? Let's hash this through," and be able to converse at the higher level of where exactly are we going because normally you have fallen into this rhythm, or you've got a driver, you got a navigator but then sometimes you have to stop. You have to take your bearing and realizing when that time is and naturally transition into that, and be able to discuss the problem at its highest level where the code really and the tools that you're using really fade away into the background. They're not important.
Then you can transition back and I'm looking for a pair in that conversation and I'm looking especially for someone who can teach me something. If there's a knowledge gap that I have or a perspective that I haven't seen, so when I'm looking for where it is that we're going, if someone helps me pair around a corner, that's a huge indicator that this person is senior. Because not only do they have that perception but they can also share it with me and they can effectively argue for it and make me see it, as well.
BRANDON: Another thing for me in that same vein is the ability to be challenged. Like, for a person to challenge and be challenged. So they go, "Hey, I have an opinion about this," and you go, "Well, what about this?" And they're like, "Gosh. I never really thought about that." Or they defend their position or they push you on something, "Why don't you do it this way?" And you're like, "Well, I've always done it this way but let's try it your way."
So the ability to challenge and be challenged particularly, that is sussed out in a pairing interview, you could probably do that asynchronously through a pull request and stuff like that. But just being able to suss out, whether somebody can challenge and be challenged as a part of the educational process means that this person sharpens the people around them and they're sharpened by the people around them.
CHARLES: Absolutely. I am looking for that ability to be collaborative at that level and to educate those people around them just by virtue of their interaction.
BRANDON: One thing that sort of heretical in some circles and it seems weird to me but if you look at 95% of jobs descriptions, they will tell you, "We are looking for X number of years in X technology," and I don't want to discount the years thing. The thing is gaining experience takes hours of practice, of dedicated practice and those hours add up to years. So you're typically you are talking in the scale of years when you're talking about experience so there's not really a way around the fact that you were going to be talking on the scale of years.
I think that's not worthy of too much debate. It can take some people two years to learn something. It might take somebody else 10. But that you are talking about a scale of years. The thing that I want to challenge is the idea that language and framework experience is the thing that you're looking for. We have a lot of counter experience so that where people cross those boundaries and lines so I didn't really have that thought before talking to you about this so you kind of pushed my thinking in this regard, like why don't we care about that or why do we care less about that than others might?
CHARLES: From my perspective, it kind of flies in the face of the way we operate. If we're requiring that someone have a certain number of years of one particular technology, we're asking them to be curious. We're asking them to be diverse. We're asking them to be able to be fluid and slot themselves into any problem space. So, why would we then demand all of those things and then, "By the way, you need to be able to be slotted into this problem space to come work here."
I think that something that gets overused in the industry. I think it does make sense in certain cases. For example, not for a developer position, it's less than $250,000. Like if you want someone with five years of MySQL experience or something to manage who has to do micro-optimizations for these huge scale things and you want to pay them half a million dollars, because that's the thing that you need, you really need somebody with that much experience in that technology. Well gosh, they'd better be charging you a lot of money for that experience. Like, "You literally want to buy five years of my life? Okay. I can do that. But I'm going to think if that really is your need, that's what I'm going to be charging you for."
But we're looking for people who will be able to move into any problem space that we come across and that necessarily implies language and framework. In fact, one of the things that I like best, I talked about evaluating for the ability to teach and that was inside the context of the one project that we're looking at, but I've had great experiences where someone has taught me something completely outside of certainly my level of expertise, and sometimes outside of what I've even heard of before.
That's a much better like if we're working on a JavaScript project, and you can say, "Oh, this is how we do things in Scala, and maybe we can apply that here." Man, that is so valuable, and that has nothing to do with JavaScript experience and everything not to do with it. So what we're looking for is you to be able to bring to bear the arsenal of tools that you have developed throughout the course of your career and all zero them in on a problem and just blast it out of the water. So why would you limit that? Why bring one gun when you can bring 30, and one of them is a howitzer.
BRANDON: That makes a ton of sense. It's the idea that is connected to our purpose which is like one of our purposes in existence is to advance the state of the art in UI engineering. That may sound like BS but it's very true. That is very much why you get up in the morning and come to work. It's like half of it is about creating a generation of leaders, and half of it is advancing the state of the art in UI engineering.
Advancing the state of the art in UI engineering is not going to happen if you only bring people in who already think the things that everybody else is already thinking in UI engineering. So, we need people with orthogonal experience in other things so it's the diversity of experience that actually helps us get closer to that goal. Bringing tool sets from alternate languages and frameworks is a huge way to bring that to bear.
I also think it's a way that our industry is like an adorable little baby. It's adorable. Basically, 95% of the people in our industry are generalists, and we hire, as if we're all hiring for the 5% that is a specialist because we don't know how to do this as an industry. We're just a baby. When you think about it, it is kind of adorable. We're all kind of making this up as we go along so if we can start like the goal here is to kind of push this conversation forward and understand, maybe it's counterintuitive to hire a passionate specialist when what you're looking for is a stable generalist, primarily as an industry.
Start understanding, maybe these are some of the ways that we've accidentally been making our industry narrower and less diverse is we're looking for people that started programming on a TRS-80 back in 1984 or whatever. And so the problems that come along with that, we're starting to have to struggle and cope with now. So, anyway, in our own tiny little corner of the universe just for our local maximum of trying to build a better software consultancy, it makes a ton of sense for us to look for generalists.
CHARLES: Yeah, that's definitely fits right with our value proposition is that we do UI but we can apply our UI skills to any number of problems. But it might not make sense. Like I said, if you're managing some gigantic database cluster and you need really, really, really specific skills, I just hope whoever that is you're charging a lot of money.
BRANDON: Yeah, you can get away with generalizing and going, "Hey, I'm going to select for a lot of things." But if you're going to specialize, you basically have to go for money. I think we're getting into the place where we're pulling this into a tight 30 minutes. We've got to wrap this up.
There's always a million more things to say on these topics but I feel like, I've learned a lot through the course of preparing and then doing this with you today to around like why we do what we do? What we're looking for technically? It'd be really cool, 'Hint, hint', that this turned into a blog post on your part. Because I do feel like it was the piece that was missing in people that kind of riled them up a little bit. It is an important piece like not to just --
CHARLES: It's okay people, we do care about technology. We do care about technical skill. In fact, we are a company dedicated to developing it.
BRANDON: Yeah, that's true. People have to walk out with more of that than they walk in with or we fail. But that's not going to stop the people from yelling at you.
CHARLES: Hey, it's fun. It's fun to yell on Twitter.
BRANDON: It is funny. It's fun. All right, man. Well, this was really cool and I hope we get to do this again. We basically are in the process of kind of rebooting our podcast and getting in on track while we record it. Every two weeks at least, we have guests lined up --
CHARLES: Do we want to share like a sneak preview?
BRANDON: Oh, gosh. Yeah, I mean with the people that we're talking to soon, we're going to have a conversation with Ember Sherpa about apprenticeship. We're going to have a conversation with Leah Silber about building communities. Then, there's a ton more in the hopper. This is going to be a really good rest of the year for this podcast and we're going to get consistent about it and we've hired help with it. We're really excited to have Mandy Moore. She's @DevReps on Twitter, if you are looking for any assistance with stuff like this. And we're really excited to start kind of kicking off a new --
CHARLES: A new era.
BRANDON: But for those of you --
CHARLES: For those who like the intermittent, unreliable, yet sometimes pleasing dead cast, we'll interleave a few of those too.
BRANDON: We'll do our best but this is yeah, for those people, I must apologize. I really liked how infrequent it was. Like, oh man. Maybe just check in every once in a while.
CHARLES: Yeah, it's cool. All right.
BRANDON: Charles, it's been great talking to and I can't wait for next time.
CHARLES: Yep, likewise, man.
