Episode Summary
Sean Kilgore is a senior principal engineer/architect at Twilio. Sean brings more than two decades worth of tech experience to this role. Previously, he worked as a principal engineer II/operations architect at SendGrid (which was acquired by Twilio), an operations engineer at Beachhead Studio, and an associate system administrator at Blizzard Entertainment, among other positions.
Join Corey and Sean as they talk about becoming a manager and underestimating the emotional outlay that's needed to manage humans effectively, the difference between engineers and architects and what it's like to influence without authority, what the transition was like after Twilio purchased SendGrid, what it's like to have 11 job titles in eight years at one company, how staying at the same company for too long often results in underpaid employees but how Twilio has shattered that mold, how you can tell a lot about a company by the way they buy their people, and more.
Episode Show Notes & Transcript
About Sean
Sean Kilgore is an Architect at Twilio, where he draws boxes, lighthouses and soapboxes. In Sean’s spare time, he enjoys reading, walking, gaming, and a well-made drink.
Links:
- Twilio: https://www.twilio.com/
- Silvia Botros's Twitter: https://twitter.com/dbsmasher
- Sean's Twitter: https://twitter.com/log1kal
Transcript
Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.
Corey: Your company might be stuck in the middle of a DevOps revolution without even realizing it. Lucky you! Does your company culture discourage risk? Are you willing to admit it? Does your team have clear responsibilities? Depends on who you ask. Are you struggling to get buy in on DevOps practices? Well, download the 2021 State of DevOps report brought to you annually by Puppet since 2011 to explore the trends and blockers keeping evolution firms stuck in the middle of their DevOps evolution. Because they fail to evolve or die like dinosaurs. The significance of organizational buy in, and oh it is significant indeed, and why team identities and interaction models matter. Not to mention weither the use of automation and the cloud translate to DevOps success. All that and more awaits you. Visit: www.puppet.com to download your copy of the report now!
Corey: Up next we’ve got the latest hits from Veem. Its climbing charts everywhere and soon its going to climb right into your heart. Here it is!
Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. I’m joined this week by Sean Kilgore who’s an architect at a small company called Twilio. Sean, welcome to the show.
Sean: Corey, it’s a pleasure to be here.
Corey: It really is. You’re one of those fun people that I always mean to catch up with and really do a deep dive in, but we keep passing like ships in the night. And in fact, I want to go back to more or less what is pretty damn close to your first real job in technology. You were a
network administrator at Lutheran High School in Orange, California.
network administrator at Lutheran High School in Orange, California.
Sean: I was.
Corey: And at that same time, I was a network administrator down the street at Chapman University, also in Orange, California. And despite that, we have traveled in many of the same circles since, but we have never met in person despite copious opportunities to do so.
Sean: That is amazing.
Corey: Talking to you is like looking into a funhouse mirror of what would it have been like if I could, you know, hold down a job, and was actually good at things. It’s really fun. Apparently, I’d be able to grow a better beard.
Sean: I don’t know about that. My beard is pretty patchy.
Corey: Yeah, I look like an angry 14-year-old trying to prove a point to Mommy and Daddy. But that’s not really the direction that we need to take this in today. And you’ve done a lot of stuff that aligns with things that are near and dear to my heart. For the last—what is it now?—six years and change? Seven years and change? You’ve been at SendGrid, then Twilio through acquisition?
Sean: Mm-hm.
Corey: And you have done basically every operations-looking job at that company. You’ve had a bunch of titles. You wound up going from DevOps engineer to a team lead, then to a senior DevOps engineer again, and you call—you voluntarily move back to an individual contributor role. Let’s start there. What was management like?
Sean: The management was interesting. My first go at that, I had no idea what I was doing, and so I didn’t know how to ask for the help that I needed. And so my wife and I refer to that time as the time that I played a lot of video games. Just, I wasn’t prepared for the emotional outlay that managing humans costs. And so I would end up spending my nights just playing video games trying to unwind and unpack from all that.
I’ve managed twice, now. The second time was—it went much better. I knew more of what I was doing, I had more support. The manager of the team that had left, I had worked with that team very closely in the past, I’d been part of it. And so my whole purpose there was to make sure that we didn’t lose anybody after that until we found a new manager.
And that actually worked out pretty well. I had to have some really difficult conversations with some people along the way, but they all stayed, they all told me that they really enjoyed me managing them. And I’ve had people ask me to manage them again after that, which was super bonkers.
Corey: It’s always flattering when you have an impact as a manager and people seek you out to work with you again. I dabbled in management as well; no one ever asked me to do it twice, and I have effectively avoided managing people here at The Duckbill Group, just because my belief of what a good manager is—and I think it aligns with what you’ve already said—requires a certain selflessness and ability to focus on others and grow them, whereas my role here is very much as face of the company, and it’s about me. That’s not a recipe for a successful
outcome for managing people and not having them rage-quit.
outcome for managing people and not having them rage-quit.
Sean: Definitely.
Corey: One thing that I find is interesting about management, the higher you rise in an organization, it’s counterintuitive but the more responsibility you get, but the less you can directly affect yourself. Your entire world becomes about effectively delegating work to others and about influence. In your case now, you are an architect, which means different things at different companies. So, I’m not entirely sure I know what it means at Twilio. So first, what is an architect at Twilio? And where does your responsibility start and stop, I guess is where I want to go, there?
Sean: So, architecture at Twilio is kind of different. Some of the architects that I’ve worked with in the past is the ‘I design everything, and then engineers go and build the thing that I designed.’
Corey: Oh, yes. The enterprise architect approach where I’m going to sit in my ivory tower and dispatch, effectively, winged monkeys to
implement things that I don’t fully understand, but I have the flashy title. You’re saying that’s not what it is?
implement things that I don’t fully understand, but I have the flashy title. You’re saying that’s not what it is?
Sean: There’s a fine distinction here because I think that some of the people I work with would definitely say that I am up in my ivory tower. It is more about—if I’m looking five years out—what capabilities my teams need to be able to provide to execute against a business strategy. That landscape is going to change immensely along the way, and so my job isn’t to say, “We’re going to use Kubernetes because that’s what we need to do five years out.” It happens to be what I’m saying right now, and I’m sure we’re going to go into that, Corey, but it’s less about this is how each of these things should be strung together to achieve that goal and more direction setting. So, I worked on something that I call the ‘Lighthouse,’ and it’s a vision of the future of where we want to go but the caveat is that if you actually go to the Lighthouse, it means you
hit the rocks.
hit the rocks.
It’s describing what I call the ‘Bay of Appropriate Futures,’ and you want to land somewhere in that Bay, but it’s not going to be the thing I wrote down five years before we get there. And so it’s much more of a technical leadership position, trying to help other technologists make good technology decisions. And so it’s more about making sure that all of the right questions get asked, not having all the right answers. That’s the difference between some architects that I’ve worked with in the past.
Corey: And one of the challenges in that role is that you’re not managing people directly. So, what that means is, you are, on some level, not doing a lot of the hands-on keyboard implementation work yourself and, unless I dramatically misunderstand your corporate culture, you’re not empowered to unilaterally fire people, which means that you can only really lead via example and influence. Tell me about that.
Sean: When people ask me if they want to be architects, I ask them if they can influence without authority, or if that’s even interesting to them. That is definitely the thing. And so when it comes down to, “Man, I really wish I could fire this person.” A, that never happens. But, B, it’s definitely about modeling behaviors. And there’s a bit of management here in that making expectations clear of senior engineers is part of my job, and helping them also be examples for other engineers is definitely a thing I get graded on.
Corey: Influence without authority is sort of the definitional characteristic of being a consultant. It turns out, you can’t even force anything; it has to be the strength of your ideas combined, in some shops, and I admit I have a bit of a somewhat cynical view on this, but also the ability for the client to commit to their sunk-cost fallacy of, “Well, we paid a lot of money to hear this advice, we should probably do something with it.” And there’s always a story of making sure that you’re serving the organization with which you work, well. But when you can only influence rather than direct, it becomes a much more nuanced thing, and I feel like the single differentiator between success and failure in that role is, fundamentally, empathy. Am I wrong on that?
Sean: Not at all. When I’m working with a very in-the-code engineer who comes to me and is trying to convince their team that they should do something, one of the things that’s a stumbling block for them is that they don’t realize that other people need to be influenced in ways that might be different than the way that they’re influenced. So, as an example, I work with a team of very senior people; I know that some people will respond well, if I site Accelerate, for example. And some people want to hear, “Well, Google does this, so it’s obvious that we should do that.” And trying to thread that needle with everyone in a way that gets everyone on board in the best way for all of us, when you can do that, you can be an architect.
Corey: Some weeks, I feel like I’m closer to architect than I do others. It seems that the idea now—solutions architect being a job role that a lot of companies have they hurl out into the universe—is in many ways vastly misunderstood. You want to talk about some kind of architecture story, where I’m going to go ahead and design an architecture that solves some business problem on a whiteboard. That’s not hard to do.
The hard part is then controlling for constraints such as, “Yeah, we already have a thing that doesn’t look anything like that, and we want to get it to that point. And oh, by the way, 18 months of downtime while we do that is not acceptable.” Nothing is ever truly greenfield. And adapting to constraints, and making compromises, and being realistic seems to separate the folks who are good at that from the folks who are
playacting.
playacting.
Sean: There’s another thing in there where people who’ve worked on the same thing for a long time sometimes have a problem seeing where you could go. And so the constraints there can be really useful in designing things. A lot of people think that greenfield is awesome, but greenfield just means the possible outcomes are the entire universe. I like working in constraints, essentially.
Corey: So, I want to talk to you a little bit about your tenure at Twilio, where you started off at SendGrid and then there was an acquisition, and everyone I know got super-quiet for a while because it turns out when there’s a pending acquisition, talking to people about it is frowned upon, and that goes doubly so in the context of someone who basically shitposts for a living. And I get that; I respect confidentiality, but I also don’t want people to jeopardize their own positions. So, it’s one of those, “Yeah, whatever you’re comfortable telling me, or not, is fine.” So, we didn’t talk for a while. And then the acquisition happened, and now you’re there. And you’ve been there at Twilio for a couple of years or so and haven’t rage-quit, so apparently, it’s worked. What was the transition like?
Sean: The transition was really interesting. A lot of people were telling me that acquisitions were universally horrible. And that’s not how it worked. This is the first acquisition I’ve been through, so I have no context. People I trust told me that this one went well.
So, in my role as architect, this acquisition was kind of interesting because SendGrid had a very robust, and we’ve done architecture for years. And Twilio’s architecture was a little bit different. It was more like, “There are some really, really senior people at Twilio who have seen some things, and you should probably ask them their opinion on stuff.” But there wasn’t really, like, an architecture review process. There was definitely, “A you need to write down a bunch of stuff and get some people to look at it,” but it wasn’t a, you need to get approved by your local architect or a group of architects.
Part of that is to provide visibility across the org so that we’re not duplicating work and stuff. But Twilio basically adopted SendGrid’s architecture process, but it grew 10x. So, at SendGrid, we had, I think, six architects. At Twilio, we have, like, 40 now, so not quite 10x. But trying to copy and paste that process was kind of rough.
We’re still, kind of, making that better. And then there were a couple things—as the acquired company, you kind of expect, I don’t know, maybe some housecleaning to happen. And that isn’t what happened. We saw a lot of like really senior leaders move into positions at Twilio of leadership. So, on day one, I think SendGrid’s sales leader became the sales leader for all of Twilio.
And that sounded—I haven’t done this before, but it sounded like that’s not normal. And that’s happened in a couple different spots. It’s been pretty neat. And when I think about the acquisition, not just of acquiring another channel for Twilio, but kind of doing an acqui-hire of a bunch of key positions, that was a pretty valuable one.
Corey: Let’s talk about one aspect of working at Twilio that I profoundly envy you for, which is working with one of the greatest people in the world: Silvia. Let’s talk about Silvia.
Sean: She interviewed me at SendGrid. She’s been here almost a year longer than I have, and it’s been such a joy to work with her. Not just because everything gets Botros’ed around her, and so we have our own built-in chaos monkeys, but also, there’s no one that cares more about making sure that what teams are building won’t come back and bite the team later. She’s worked with, I think, maybe a 10th of the company now—and at Twilio, that’s a lot of teams—trying to just help them do better and make sure that the stuff that they’re building is not going to page them all the time, is actually going to serve the customer in ways that isn’t surprising to the customer. I can probably talk for half an hour about my appreciation for Silvia.
Corey: Well, she was a great guest in the early days of this podcast. Silvia Botros is phenomenal. She has the Twitter handle of @dbsmasher so she’s my default go-to on misusing things as databases. And she also was just one of the most genuinely kind people I know.
She also has an aura effect, where she is basically a walking EMP, and every time someone tries to show her a piece of technology, it explodes in novel and interesting ways, which, frankly, as an acceptance gate for technology is a terrific skill set to have. Does it cause problems in the office?
Sean: Not normally. It causes more problems in the office when we are actually in an office together because Silvia, maybe predictively, is also a giant klutz. And so the joke is that she also EMPs herself. In the office, she does break things, but it’s never in an intended way. Or it’s just like a fun, “Oh, man, the WiFi’s down. It must be Silvia.”
Corey: Exactly. It’s always nice to have someone you can blame for these things.
Sean: It’s SOP.
Corey: Yeah, oh, absolutely. At some point do you ever wind up missing things such as, “Oh, it’s probably just Silvia. No, it was actually a problem somewhere?”
Sean: So, we actually determine that Silvia’s EMP works at a distance. She flew somewhere close to one of our hardware data centers, and at the time that she passed it, we had an outage. Like, the data center went dark, kind of thing. And so it still happens even if she’s not around. We’re pretty sure it’s not a local phenomenon.
Corey: So, the thing that I know is probably going to sound completely boring and ridiculous to half the audience while the other half the audience sits and listens raptly; before I started this place, I never stayed anywhere for longer than two years, because as previously disclosed in multiple directions, I am a terrible employee. First, why did you stay at the same place for as long as you have, and what’s it like? And I’m really hoping you have an answer that isn’t just, “Oh, I have a complete lack of ambition,” because I won’t believe that for a second. But it is a tempting cop-out so let me just shut that down now.
Sean: No, it’s more I’ve been here for almost eight years now, and I’ve never done the same thing. The fun fact that I tell people when they onboard or I’m interviewing them is, I think I’ve had more titles than anyone at Twilio. I’m up to 11, I think. And so 11 titles in eight years? It hasn’t been the same company.
When I started, I was employee number 150. There were 80 of us when I started at SendGrid. I work at a company with 4500 people now and going through that growth, the company that I work for today, and even pre-acquisition, you would not recognize from the day I started at SendGrid. And so if I had been doing the same thing all the time, I wouldn’t still be here. There was a point before we started architecture at SendGrid, I was definitely in a spot kind of a rut, like, “Cool. I can continue to do the same thing over and over,” but I felt like there wasn’t a lot
of growth to do.
of growth to do.
I needed to go see something else, kind of thing. I knew really well how to do our mail stuff, and I felt like I needed to broaden my horizons a
bit, or I needed to level up. And at the time, the only place to go up was to management. And then we brought in a chief architect, J.R. Jasperson, and I I remember very clearly, it was like his third day or something, we had an all-company meeting—like a lunch thing—and I walked up to him and said, “You don’t know this yet, but you’re my new mentor because it seems like what you’re talking about is really interesting to me.” And he didn’t know it but the subtext there was like, “And if you don’t, I’m out.”
And since then, the work that I do day-to-day is completely different. Like, I work for a platform org. This platform org is 130 people right now; it spans everything from building EC2 instances to, recently, it was, like, Twilio API Edge. There’s such a breadth in there that I never do the same thing every day.
Corey: I really love installing, upgrading, and fixing security agents in my cloud estate! Why do I say that? Because I sell things, because I sell things for a company that deploys an agent, there's no other reason. Because let’s face it. Agents can be a real headache. Well, now Orca Security gives you a single tool that detects basically every risk in your cloud environment -- and that’s as easy to install and maintain as a smartphone app. It is agentless, or my intro would’ve gotten me into trouble here, but it can still see deep into your AWS workloads, while guaranteeing 100% coverage. With Orca Security, there are no overlooked assets, no DevOps headaches, and believe me you will hear from those people if you cause them headaches. and no performance hits on live environments. Connect your first cloud account in minutes and see for yourself at orca.security. Thats “Orca” as in whale, “dot” security as in that things you company claims to care about but doesn’t until right after it really should have.
Corey: That’s functionally, I think, the problem that I had in working in environments as a DevOps type because for the first three months in a job where I’m the first ops person, “Great everything’s on fire.”—I’m an adrenaline junkie in that sense—“Cool. Oh wow, all these problems that I know how to fix.” And then it gets to a reasonable level of working and now it’s just care and feeding of same. Okay, now I’m getting slightly bored, so let me look for other problems in other parts of the org.
And that doesn’t go super well when you’re not welcome in those parts of the org which leads to a whole bunch of challenges I’ve had in my career. This is incidentally why being a consultant aligns so well with me and the way I approach things. It’s cool. I’m going to come in; I’m going to fix things, and then I get to leave. On day one, we know this is a time-bound engagement and that’s okay.
Instead of going down the path of the lies everyone tells themselves where average tenure in this space is 18 to 24 months, but magically we’re all going to lie and pretend in the interview that this is their forever job and suddenly you’re going to stay here for 25 years and get a pension and a gold watch when you retire. And it’s, oh wow that’s amazing it sounds like everybody having these conversations wearing old-timey stovepipe hats. There’s just so much that isn’t realistic in those conversations. So, I talk to people who’ve been down those paths who’ve been at the same company for a decade or two, and the common failure mode there is that they have a year or so of experience that they repeat 10 or 20 times. And that’s sad; people get stuck. What you say absolutely resonates with me in that every year is a different thing that you’re working on. You’re not doing the same thing twice. I get antsy when too many days look the same, one to the next.
Sean: I definitely hear that. If my every day was, come in join a stand-up, talk about the problem that I had last week and still have today, it wouldn’t work for me. I feel lucky that I work for an organization where outside input is actually requested and honored, so if I go to a team and just happened to have noticed something and say, “Hey, this right here you might want to take a look at. And I have some opinions here if you’d like to hear them.” I normally get asked for that opinion, and it normally turns out pretty good.
There’s definitely times where it’s been, like, “No, Sean. You don’t know what you’re talking about.” And normally they’re right. It’s definitely not the same. People say you should be at a company for 18 to 24 months. And that’s true if your company is totally shortchanging you. When I ask my peers at other companies about, have I gotten stiffed by staying at the same place for this long? It’s definitely not. And if that wasn’t true, if Twilio was holding back my compensation, maybe this would have gone a different way, but it’s not what’s happened.
Corey: Oh, true and to be clear that is very often the biggest criticism I have of people who stay at one company for a long time. They don’t realize what market rate is anymore and they find themselves in a scenario where, “Wow, I could go somewhere else and triple my salary,” which is not an exaggeration and an unpleasant discovery when people realize that they’ve been taken advantage of. And credit where due, I have had conversations with people at Twilio who have been there a long time. And I have never gotten the impression that that is what’s going on there. Your compensation is fair. I want to be very clear here. This is not one of those, “Oh, yeah, I’m just trying to be polite because someone’s being taken advantage of and doesn’t even know it.” No. They’re doing right by their employees. The fact that I have to call them out explicitly as an example of a rarity of a company doing right by its employees, is monstrous.
Sean: It is. We’ve hired a few people recently where I found out that I think their pay was close to doubled just by coming here, and I just wish that it was more okay to call out their prior employees publicly and be like, “Cool. If you work for this company will probably pay you a ton more.”
Corey: And that’s the other side of it, too, which I did early on in my career. It’s, “Oh, I’m leaving this company and screw you all.” “Well, why are you leaving?” “Oh, because I’m getting a 5% raise to change jobs.” I’m not saying that money should not factor into it, but at some point, when all is said and done at that scale, it works out to be 100 bucks a paycheck, or so, is it really worth changing for that? Maybe.
If there are things you don’t like about the environment, please don’t let me dissuade people from interviewing for jobs. You always should be doing that, on some level, just so what the market looks like. But I’m also a big believer in, you don’t need to be as mercenary as I was early on in my career. A lot of it was shaped by environments—not Chapman, I want to be clear—that were not particularly kind to staff. And that I felt taken advantage of because I was. And as a result, “Oh, screw me? Screw you.” And it became a very mercenary approach that didn’t serve me well. That is now a baked-in aspect of how I view careers in some respects, and that is something of a problem that I wrestle with.
Sean: The mercenary thing?
Corey: Yeah. I wrestle with the mercenary thing just because when I talk to someone who’s having a challenge at work, or something, my default instinctive gut reaction that I’ve learned to suppress is, “Oh, screw ‘em. Quit and find another job.”
Sean: Ah, gotcha.
Corey: That’s not the most constructive way to work in the context of a company where you’re building a career trajectory, and a reputation, and you’ve been there for five years, and maybe rage-quitting because you didn’t wind up getting to pick the title of that presentation isn’t the best answer. I can be remarkably petty, for the reasons I’ll leave a company. But that’s not constructive, and I try very hard to avoid giving that advice unnecessarily to people.
Sean: It’s definitely just, like, incidents, right? It’s never a root cause; it’s a contributing factor, and pay is just one contributing factor. I find that a lot of people, even if they’re being taken advantage of compensation-wise, they won’t leave unless there’s something else wrong.
Corey: Yeah, compensation is absolutely a symptom, and in most cases, that’s not the real reason people are going to leave. I assure you, people who work at The Duckbill Group could make more money, objectively, somewhere else. But there’s a question of what people value. We pay people well, but we don’t offer FAANG money, with the equity upside and the rest. We’re not trying to pull the Netflix and pay absolute top-of-market in all cases to all people.
I would love to be able to do that; our margins don’t yet support that. Thanks to our sponsors, we’re going to continue to ratchet those prices way up. I kid. I kid. But there are business reasons why things are the way they are. What we do offer instead is things that contribute to a workplace we want to work at. More of us are parents than aren’t.
We don’t expect people to work outside of business hours in almost any scenario, short of, you know, re:Invent or something. There’s a very human approach to it. We’re not VC-backed at all, so we don’t ever have to worry about trying to sprint to hit milestones over debt as a company. We have this insane secret approach called ‘revenue’ and ‘profitability’ that means we can continue to iterate month to month, and as long as the trend line continues, we’re happy.
Sean: That kind of sustainability is awesome, and is a really good indicator that a company is going to be successful, to me. Especially smaller companies; the decision to not take VC money. And to chase sustainable revenue growth, I know everyone wants to chase the hockey sticks, but at what cost?
Corey: Yeah. And I think that people put this on job-seekers way too much. I have been confronted, at one point—I will not name the company—when I was interviewing years ago, and I was asked by the hiring manager, “Well, it seems like you’ve done a fair bit of job-hopping in the course of your career. What’s up with that?” And they pulled up my LinkedIn profile and went through it, and I said, “You realize most of those were contract gigs?” “Well, I don’t kno—oh, yeah. I guess it was. Oh, that was—huh. I guess so.”
So, it was a failed attempt to call bullshit on my job history. And because I don’t take things like that well, I turned it around right back on him, and I said, “No, I appreciate that. Thank you for clarifying.” That’s a warning sign is when I thank you for insulting me because what’s coming next is always going to sting. But while we’re on the topic of turnover, “Your team has lost 80% of its members in the last six months. What’s going on with that? Is there a problem here that I should be aware of?” And suddenly, the back-peddling was phenomenal. I did get an offer from that company; I did not accept it.
Sean: Good.
Corey: You can tell a lot about a company by how they buy their people. And if you’re actively being insulted or hazed in the job interview process, no. I want people who I choose not to hire, to come away from the experience feeling respected and that they enjoyed the experience to the point where they would say nice things about us if asked, or even evangelize us without ever even having to be asked. And so far, we’ve done that because we’re very intentional on how we approach things. And man, am I tired of people doing this badly.
Sean: When I interview someone, I want them to leave, and then if they don’t take the job, I want it to be because it wasn’t the right job for them. Or, like, the team wasn’t the right fit, not because anything happened in the interview process that was a red flag. That’s the worst. I want Twilio to be a spot where there are no red flags. That would be ideal.
Corey: Absolutely. I think that so many folks get it wrong, where there’s this idea of, “Oh, I’m going to interview you. And oh, you’re an ops person. Great. I want you to implement Quicksort on the whiteboard.” And it’s, “Question one: do you do that a lot here? And two: no, of course you don’t because I’ve seen your services list. There’s no rhyme or reason to the order it appears in. Maybe someone should implement Quicksort in production.”
And then there’s the other side, too, of, “Oh, great. There’s this broad skill set across the entire space. I’m going to figure out where you’re weak and then needle you on those.” I don’t like hiring for absence of weakness; I like hiring for, you’re really good at things we need here and you’re acceptable at the things that are non-negotiable, and able to improve in areas where it becomes helpful.
Sean: Yeah. The best interview process I ever had, they flew me up to San Francisco, I worked with them for a day on a real problem that they had, like, pair programming. They offered me the job—it didn’t work out because I didn’t want to move to San Francisco, it turned out—but that interview process was super valuable to me as the candidate because I found out exactly how a day at that job would work; what it would
look like.
look like.
Corey: I had a very similar experience once and the cherry on the top was they paid me a nominal contracting rate for the day—
Sean: Same.
Corey: —because it was touching things that they were doing. And I think that that’s another anti-pattern of, that was a thing that also just happens to be a thing we’re going to use in production, but we’re not going to tell you that we’re not going to compensate you for it. I’ll work on toy problems; not production in an interview context.
Sean: I wanted to circle back to one thing about leaving a company, like, rage-quitting. It’s essentially—if you rage-quit because of a problem, like, a small thing, you’re missing an opportunity to grow. And especially if I had one superpower, I would say that it’s probably managing up. Part of this is just, I have a lot of privilege that lets me do that, but it is definitely a skill that I wish more people had for their own careers.
Corey: I really do, too. We spent all this time practicing how to be a candidate in a job interview, and almost no time training people how to be a good interviewer, and what you’re looking for. And you wind up with terrible things like, “I had this problem once in production that I thought was super clever, so I’m going to set it up for you and see how you would solve that problem. And if you don’t follow the exact same path that I did, then we’re going to go ahead and just keep shooting down anything else you suggest.” No, stop it.
Sean: I do a lot of interviewing, and so I love when I learn something from a candidate because I can ask them questions that are like, “How did you figure this out? How did you even notice that this was a problem?”s and you get to go really deep in something they know, the way they know it. We used to do the, like, “Build us an LRU cache in the best big-O notation time.” And if you didn’t get it, you didn’t get the job, if you did it in slower than optimum time.
And I remember leaving one of the interviews and doing the recap, and it was like, if anyone came to work and did this, I would be upset at them for wasting time. This is part of the standard library of all the things that we do. Why are we asking this question? I know for a while we stopped asking the question, which is great. I don’t do a lot of code interviews at Twilio, so I don’t know if we do something similar there, yet. I should go find out.
Corey: I do not know either way, to be clear. None of the stories I’m talking about involved Twilio. Though I will say, I went on an interview years ago at SendGrid in Anaheim, and I don’t know if I ever got a formal rejection or not afterwards, but regardless, they did not opt to hire me. In hindsight, good decision.
Sean: I wonder if we were in the office at the same time.
Corey: It would have been 2006, so I think it might have been a bit before your time.
Sean: That was before my time.
Corey: And very much, credit where due, I started my career in large-scale email systems, so SendGrid was one of those. Oh, I could probably apply the skill set there. The problem, of course, was that it became pretty apparent, even in those days that eventually there weren’t going to be that many companies that needed that skillset. The days of an email admin in every company were drawn to a close, and it was time to evolve or die.
Sean: You’re welcome.
Corey: Of course. And again SendGrid today, under the hood—deep under the hood—does still power Last Week in AWS. You folks send emails and get them where they need to go, for which I thank you, and the rest of the world probably does not most weeks.
Sean: [laugh]. Yeah.
Corey: Ugh. So, we’ve covered a lot of wide-ranging topics. If people want to hear more about who you are, and what you have to say, where can they find you?
Sean: I’m on Twitter at @log1kal with a one and a K because I hate people who want to find me, apparently. But that’s @log1kal. Twitter’s probably the only thing.
Corey: Excellent. We’ll, of course, put a link to that in the [show notes 00:30:39]. Sean, thank you so much for speaking with me today. I really appreciate it.
Sean: Thank you so much, Corey. I love having these kinds of conversations. I love that there is no plan; we’re just going to have a conversation and record it. I love listening to these kinds of podcasts.
Corey: Well, I like creating these kinds of podcasts because the other ones take way too much work.
Sean: [laugh].
Corey: Sean Kilgore, architect at Twilio. I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice along with a comment explaining how it is almost certainly the fault of Silvia Botros’s aura.
Sean: [laugh].
Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.
This has been a HumblePod production. Stay humble.
