This automatically-generated transcript is taken from the IT Pro Podcast episode ‘Do degrees make better developers?'. To listen to the full episode, click here. We apologise for any errors.
Adam Shepherd
Hi, I'm Adam Shepherd…
Connor Jones
and I'm Connor Jones.
Adam
And you're listening to the IT Pro Podcast, where this week we're talking about what it takes to make it as a developer.
Connor
It's no secret that we're in the midst of a talent crunch. Software developers and engineers are in more demand than ever, and seemingly every company is fighting for skilled technical employees. At the same time, companies are under increasing pressure to improve the diversity of their workforces, and create more representative teams.
Adam
With all this in mind then, why do so many organisations still structure their recruitment criteria around restrictive ideas of what to look for in candidates? This week, we're joined by Rob Zuber, CTO of DevOps software company CircleCI, to discuss why organisations need to stop focusing on degrees and qualifications and talk about what it actually means to be a good coder. Rob, thanks for being with us.
Rob Zuber
Thanks so much for having me. It's a pleasure to be here.
Adam
So Rob, to kick off with then, can you tell us how many developers you have in your organisation?
Rob
Yeah, our engineering organisation is about 250 folks, including management, but about 250 overall.
Adam
And how many of them roughly came through what you might call the traditional university route?
Rob
Well, I guess honestly, in line with the topic, it's not something that we pay a huge amount of attention to, because it's not something that we spend a lot of time screening for. But I would say, it's still the vast majority, mostly as a result of the paths that people follow to get into software in the first place. Like the things that that end up filtering along the way, I guess, end up impacting us whether we, you know, specifically look for those things or not.
Connor
Cool. And there are a number of different sort of popular routes into IT in the UK, I've done a bit of work on it in the past, in terms of, well, if you've got the degree route, and then in England, we have well, in Britain, I should say, we have a degree apprentice programme across the country, which is sort of like more hands on with a little bit of academics, maybe like once a week. Aside from sort of the university route, and maybe like, a boot camp, what are sort of the main routes that you typically see when you have applicants apply to you guys?
Rob
Yeah, I mean, there's actually a really broad variety. I would say those are still primary, although, you know, we also have to think about at what stage in people's career are we are we hiring them? You know, we are obviously not hiring all of our folks directly out of college or at that sort of entry level. And so we have folks who have, you know, done all sorts of things to get to the point where they are at higher levels of experience and joining us, and then yeah, we have folks coming in through boot camps, we have folks who, you know, maybe just like, it's hard to say what the path was, but you know, didn't necessarily go to college or university. Sorry, I'll take a small pause. Because as a Canadian living in the United States, the terminology, like I flip back and forth, but I went to university as I would describe it, but here we would call it College, as you know, university versus community college. So but I mean that so a sort of three year community college is a totally viable path. What we would call university, totally viable path - or doing something else. Like we have folks very high in our, in our leadership organisation within engineering who, you know, left high school, went and did other things, found other jobs, and then sort of maybe ended up in technical roles that weren't engineering out of the gate; support, sales engineering, like, oh, you know, I enjoy being around people. Well, maybe I enjoy being around people less than I really liked the software element of it. I mean, I personally do have a university degree, but not in computer science. And so I, you know, I left school, went to work in a in a factory, in a production facility as an engineer, analysing basically, defects and effectiveness of our quality, or of our production from a quality perspective, I enjoyed the analytic piece, started writing software tools to solve my problems personally, and then enjoyed the software more than the factory and you know, some friends started a start up, and there we go. That was a really long time ago, but, and that may be different, right? Like when I look back at the people that I work with in software who graduated in the 90s, you know, when we were going to school, it wasn't obvious that there was a great, you know, that that computer science was going to be the path sort of thing. So people did all kinds of different things. Like some of my favourite software developers have degrees in things like Russian linguistics, you know, like, like, just completely random things. I mean, no offense, those are totally viable degrees, but but then came out and said, this is this is my affinity, in a sense, right? Like, and I think that's really the core of this discussion is not like, what was I taught in school, because, like, to be totally honest, you come out of even a university degree in computer science kind of scratching the surface of what you're going to do as a job. And particularly as you proceed, right, as you grow to higher levels, you move from technical proficiency into a whole bunch of different other aspects of what the job entails. I mean, we were joking before we started that the one thing I definitely do not do now is write code as as CTO, right, so. So the kinds of mental tools that you need to have can be very, very different as you proceed through the levels of software engineering. And so, you know, the technical proficiency, honestly, you could pick up a lot of different ways.
Adam
And also one of the one of the problems that we've heard about with, particularly, you know, university computer science education, is that it takes, you know, takes about three years to go through a standard kind of university course, it's probably taken at least kind of best part of a year to put that curriculum together in the first place, even if it's an entirely new curriculum. Four years in the world of software and technology, you know, everyone listening to this podcast will know, is a aeons. The industry will have moved on so much, by the time you get out of that course, that you'll you know, in all probability, you'll have to relearn a whole bunch of stuff, and unlearn a lot of stuff as well.
Rob
Absolutely. So I mean, I've alluded to it, my degree is in engineering physics. And I often comment that the thing that I learned was to learn a whole bunch of stuff very, very quickly, right? Like it was, yeah, tonnes of courses, tonnes of labs, like just it was a lot of hard content. And I don't use any of it day to day other than in analogies that I keep making that no one understands. The ability to take a complex subject and consume it rapidly is a skill that I learned there. And, you know, did I need to go to a university to learn that skill? Probably not. I would say, the, you know, the first startup that I ended up working at, was started by people that I went to school with. So I mean, that part like, you know, people make allusions to it, but the the networks that we build, the friends that we we make, the ability to learn, or learning how to learn, those are all those are all attributes, I guess, or outcomes of spending four years at a university. And so, you know, if, if you're looking at this from the side of someone who's interested in this career, then those are things to think about, where can I get those things, there's a million places you can get them, it doesn't have to be at school. And then coming from the other side, if you're looking at that, as a employer who's under pressure to hire, to deliver, and in a in a crunch, like, we can be a lot more creative about how we look at folks and ask the questions, you know, are they are they going to succeed here? Right, I think, and can I make them succeed, which I hope is a subject that we'll get into, which is the really hard part, it's easy to say, well, we're just going to change the way that we look at candidates. But most organisations, I believe, are also built to help the candidates that they've been looking for succeed, not the ones that they're now going to go look for. So they have to rethink that piece as well.
Adam
Yeah. So speaking of which, then, where do you think companies should be looking for new developers outside of these traditional kind of these traditional sources, whether that's traditional in the sense of kind of university education, or traditional in the sense of kind of specifically, computer science and software engineering degrees?
Rob
It's a great question. It's hard to describe for me where to go look, I mean, turning over rocks is a really hard thing for all of us. But I, you know, it's a question of understanding what kind of what attributes to look for. And I think that one of the things that I personally look for, this is probably a bias because of, you know, I've spent a lot of my life in small startups is, is best described, described as scrappiness. I don't know how well that expression carries over but, you know, people that have perhaps, left school early, didn't go to college, but started something, right? Didn't, you know, I don't know how to describe it, but just like, I started a little business, whether that's in my local neighbourhood or at some bigger scale, you know, like, even starting an online business is, uh, you know, super simple, I could set something up on Shopify and just be selling something interesting, right? Because I think that, you know, again, talking about that arc of a software developer, at some point you go from do I have technical proficiency to do I understand customers, right? Do I understand the needs of my users? And can I use the toolkit that I've built to support the needs of those users? And so someone who has that mentality, right? And is, is, let's say, excited, hungry, whatever expression you want to use, to really help people succeed, will be able to build out the toolkit, they'll be motivated to build out the toolkit to help them succeed, right? So, I mean, it's an example. It's like, am I going to now go look at all the Shopify vendors and see who wants to come work for us? Like, no, but it's really a question of, like, asking, What am I looking for? Right, like, what attributes do I want? And then where could I go find those attributes? Right, like, I think it's a classic thing in, in sales, to find athletes. I mean, it's kind of a, it's just this connection that I always see, right? Because, you know, they tend to have a lot of motivation, like personal intrinsic drive, tend to be very often personable, pretty comfortable with, with the struggle, you know, like it's a lot. But those people might also make great software developers, you know, with the right mindset, I mean, the other thing I think about with developers is like, puzzles, right? A lot of developers are people who like solving puzzles.
Adam
Well, this is, this goes way back to the Second World War. Alan Turing, when they were setting up the the programme at Bletchley Park to crack the Enigma code, the way they found the candidates to come and work on that was they set a crossword competition in the Times, and everyone who won it, got a letter from the government saying, you know, come on down and work on this super secret project that we've got. So it's, that is a strategy with a long history behind it.
Rob
You know, it's so funny, because I did know that story, but wasn't thinking of it. But it's, it's totally reasonable. And I'm actually kind of terrible at crossword puzzles. So, you know, I'm glad that that's not the only path. But one thing that's great about that, I mean, in sort of in the overall arc that we're that we're discussing is, is the filters aren't the same, right? Like, one of one of the challenges that I think we struggle from when we take these classic views is we're looking at either previous companies folks have worked at and there's this, you know, people are starstruck, I just, I don't even know how to describe it. Like, that's not what matters, schools that people have gone to, whatever, and all of those have filters that are keeping you from seeing the full candidate pool, right? And so, other path, like if you can sit down and think about what pathways might make sense for you, then a lot of those are going to have less of a filter, and give you a broader perspective of the people with the potential to do the job. And honestly, that's fantastic. And at a time when, you know, we're we're all under pressure, number one and two, I think we all realise that actually bringing in a diverse group of folks and having teams made up of, of different perspectives, and different backgrounds, brings value to all of us, right, whether it's personally or as as an organisation and the products that we're building.
Connor
So coming back to our previous point that I think was a really nice segue onto our next question, which was, do you think there's an element of bias among CTOs who have you know, taken that degree-led route themselves? Whether they'll give preference to those who have a similar experience? Just because it may be like the safer option?
Rob
I will say, confidently, although I'm smirking, which no one can see, about how confidently that every CTO is going to have some kind of bias; every everybody has a bias. Right?` And it's a question of what that bias is. I think, you know, as someone who didn't come through a computer science path, my bias is towards breadth, right? But you could probably like, I'd have to sit and think about it now. But there's probably bounds of what that breadth is, in my mind. Right? However, also as an experienced CTO, meaning someone who's been in the industry over 20 years and has, you know, hired a very large number of people or had people on my team hire a large number of people, the other thing that I have in my favour is exposure to breadth even beyond what may have been my bias originally that has continued to prove to me that folks from many, many different backgrounds can succeed, and folks from the classic backgrounds can fail. So that's not the only indicator, right? Like, I think the the, I was gonna call it reps as in repetitions, like just the number of people that you've seen and worked with in your career tends to give you a broader and broader perspective. And if you have the fortune of having that be fairly broad, diverse, however you want to express it, then you'll probably also have the fortune of watching those people succeed, whatever, I won't try to list folks but like, I'm trying to think of what the extremes are of that it's, it's pretty broad, you know, it both in terms of people who have, who have really demonstrated just aptitude, affinity for the types of things that we do, and folks who, you know, have gone through a traditional background, and it turns out, it's not a great fit, which is fine, because they end up going and hopefully, finding something that is a great fit, right? Like the crossover goes both ways, you could totally go get a classic computer science degree from a top university, and have it not be something that you want to do, right. And if it's not what you want to do, like, doesn't matter how much energy you put into it, it's gonna kind of suck, and you're gonna get frustrated, and you're not going to produce at the level of someone who's just fascinated by it. Who could have, you know, any kind of background.
Connor
Okay.
Adam
so speaking as a CTO, then, what would you say is kind of is going to attract you more to a candidate, somebody that has a computer science degree, or somebody that has gone out and got a professional certification, let's say, you know, Microsoft Certified Professional, kind of, you know, AWS certifications, whatever kind of stream you want to you want to go for, which one do you think is, is kind of going to be the bigger indicator for you?
Rob
That's a really interesting question. So now you, now we can explore my biases. Well, let's do this. I think certifications for me land more in the camp that you were describing previously, which is, it's very specific knowledge, you were talking about the arc of four years of university, and you know, how long it takes to even build that curriculum. What I would say, and sort of talking about my own university, like, to me that was about learning to learn, whereas certificates tend to be, I have demonstrated that I have this specific knowledge. And I mean, I am someone who, like, grates at the please have four years of experience with this tool, or this tool or whatever, like, yeah, I don't find that particularly valuable. If you have experience with a breadth of tools, then I get the indication that you know how to select a tool for the right purpose, that you know how to use a new tool when it comes along, as opposed to the thing that you were using two years ago, because one thing we love to do in software development, I mean, is just keep changing all the tools that we use all the time, so that our jobs are harder, it's it's a weird choice. But it's a reality, right? Like that is the discipline is evolving so quickly, that the thing that matters is your ability to pick up new tools, and use those tools to come into a new environment, even you know, within a particular language, right, every company is going to use that language slightly differently. Even the ones that have very strict perspectives, everyone has their own opinion, companies ideally build their own practices and approaches. And so being able to show up and and adapt and use your, you know, your brain in that environment is what matters. So, certificates, I don't find them particularly valuable in evaluating people, I guess, I'd be looking for something else. That said, it's, it's not kind of a either-or, I'm not saying Oh, do you have a certificate or a degree, I think of those as different things, each one would tell me something different. The thing I will say about the certificate is it's a sign of motivation. Like someone has said, I really want to demonstrate that I have the skills to do this job. And maybe I don't have something else to prove that. So I'm going to go put my time and energy into doing this thing. But you could demonstrate that to me as easily with a sample project that you built, or, you know, something that shows me that you have that, you know, there's lots of other ways to for me personally. Now, of course, I am one CTO and as I said every CTO has their own bias. So like don't take my word on how you're going to navigate your entire career. But but that's how I think about them.
Connor
Cool and um, so as an industry we talk a lot about the the benefits of building dev teams with experience beyond traditional engineering backgrounds. But in your experience, which job roles do you think make the best candidates for cross-skilling into technical areas? So for example, is a cybersecurity professional getting really bored with their job? You know, they speak to their line manager and say, Well, I really fancy this change. That kind of thing, that kind of department in a business.
Rob
Yeah, so it's such a fascinating question. I think anything can work. And not everything, or not, I can't think of something that says specifically like this is I mean, if you're talking about cybersecurity, I mean, a lot of our security engineers are software engineers-plus, like, they're really good software engineers who also have a very specialised piece of experience. So if they said, I just want to go do you know, software engineering work in another team, it's kind of a no brainer, right. Whereas, if I look at the other discipline, like we talked about support, right, in our support, to be clear, you're supporting software engineers, like you're, you're very, you are an engineer, basically, you just much more customer facing. And so, you know, we've made that transition a number of times, folks spend a lot of time you know, directly with our customers, they build a huge amount of empathy, they understand our product as a whole better than most of the engineers on our team, because the engineers on the team are working on a subset of the product versus the, you know, the customer's full view. And so when they say, Hey, you know, I'm kind of interested in growing to this engineering, you know, moving into, I guess, it's a different type of engineering, but product engineering, whatever. The response is usually awesome, you know, how can we support you? Like, what do you think you would need to succeed? You know, what, what sort of interests do you have? Like, there's always a conversation, that's a great transition for us.
Adam
I mean, it comes back to the breadth point you were making earlier, right? You know, when you have that experience across all of the various facets of a product or a product portfolio, indeed, it kind of, I would imagine that puts you in a really good position to then start actually digging in and working on it.
Rob
Absolutely. And, and so the understanding of the product, but the the customer empathy is like, you just cannot discount that, right? It's so so valuable to really think about how the product functions from the view of the customer. Like, what problem are they trying to solve? It's, you know, I talked about moving through the the kind of like growing as an engineer, that's where you're starting to really mature is, okay, I have this set of tools that I know how to use, now I really have the customer mindset, I'm thinking about what problem I'm solving for them. So that that's kind of a, again, an easy one. But the the thing that I think is most interesting is the unit of production, if I can be so bold, as to call it that, in software engineering is is generally the team, not the individual. And so as an engineering manager, I am very interested in the overall makeup of that team. And so if I have five, let's say I have a team of eight people, if all eight of them are formerly support engineers, I might not have great value in that, because a couple of them could bring that perspective; then I want a different perspective, right, like someone who understands really deep, gnarly technical systems, someone else who... maybe at some point, just a totally different background.
Adam
Well, one of the ones that we've heard a few times is marketing, actually, you know, people from marketing backgrounds who want to get into the technical side of things. And because they have a lot of kind of experience with team based working and with collaborative working, and with a lot of the kind of, for want of a better term, sort of softer skills, rather than the kind of hard code experience. In a lot of cases, I've heard CTO saying yeah, like the the people that I am most invested in, in keeping hold of and getting more of are people from that kind of that softer marketing background rather than my kind of like, battle hardened, you know, dotnet guys.
Rob
Well, yeah, I mean, first in support, I guess, as a shout out to our marketing folks, like, their analytical skills are unmatched. So when you think about the kinds of things that you're bringing, right, it's a very, very different perspective of it. But most of the people that work in our marketing organisation are very, very numbers oriented, very numbers driven, think about, you know, funnels and pipelines and flows, whatever. And so, again, have a very good understanding of the product, like there's a bunch of reasons that they bring that are, you know, range across all of the skills that you would want to have. And then with that, I would say, sort of, on the softer side, one of the things that you see in teams again, focusing on the team as the unit, is folks who come in and and honestly just make everybody better, whether their specific coding skills, you know, are the thing kind of doesn't matter. Like, there's really important questions that you need to be asking and really important perspectives that you need to have within your team to succeed that have nothing to do with the ability to just write code, right? The entire agile process is framed around rituals of things like, you know, planning, estimating, understanding what the problem is you're trying to solve, connecting correctly with your product manager, making sure everyone has the context they need to succeed as they build, through to retros and saying, you know, how are we doing? Can we do this better? A lot of that, like, that's not what they teach you, I'm pretty sure, in most of your, you know, university education about computer science, but you learn all this theory about how computers work, and algorithms and data stores and all really important stuff. But then you bring that out into, you know, into that world, and the world of of developing, the day to day teamwork, and it's very, very different. And so often, I see folks who, you know, move into a team and accelerate the whole team, not because of, certainly something they learned in - well, maybe they learned it while they were in university, but it wasn't, you know, CS 201 sort of thing. Like, yeah, it wasn't very explicitly explained in a textbook.
Adam
Although I think a lot of, a lot of computer science courses would benefit from having modules on here is how you work with a business, here is how you communicate with stakeholders here is how you, you know, say no to feature creep, you know, all of these kinds of business skills that presently you kind of have to learn on the job as it were.
Rob
Yeah, I, it was a really long time ago. So it's, it's funny that I keep referring to this, but I think one of the most interesting things that I studied in, in my degree was was engineering economics 101 kind of thing like, opportunity cost, right? Evaluating different projects, net present value, you know, like, basically, where should we put our time and energy to drive them at the best return for the business. And to your point, that's a, it's not something that people necessarily sit down and think of and, and those sorts of perspectives, like, that's kind of a first bridge, it's still a very analytical perspective, but those sorts of things you do end up needing to think about as you again, grow, whether it's as a technical leader, in like a more senior engineering organisation, as an engineering manager, as a product manager. You know, those are, those are the kinds of perspectives that we want people to have. And again, at that point, you know, the technical skills are sort of a given. Right?
Connor
So what's, what would you say is the fastest way to integrate someone from a non technical background into a development or engineering team?
Rob
That's a really good question. I would say. It very much depends - it's always the answer to hard questions - in the sense that the things that are going to matter, are going to be different based on what tools that person does have, what they're bringing to the table. Right? So at the point that you're putting someone into a technical software team, you know, whatever we're describing, I would assume they have some sense of software development, some skills, and there's going to be some question about, you know, what is it that we're trying to grow for that person, that's going to be very different. And then they're bringing something else, right, there's something that you saw in that person that said, okay, this person is really gonna be able to contribute to this team. So you want to combine I think two things, one, you want to play to their strengths, right? If someone's coming in, because they bring a very customer perspective, then make sure that they continue to use that customer perspective and bring that to the team. Because for them, that's a much more rewarding experience than just okay, I'm here. I know a bunch of things, but they're not valuable. But now I'm at the bottom and trying to like climb my way up and sort of feel like I'm contributing, right, like, social acceptance, being a part of a team, feeling like you're contributing; that matters to people. So building someone up in that way. And then the other, identifying, okay, where, you know, where their gaps are? Where do we feel like we want to grow this person? And what are they looking to grow? I mean, identifying that I think is really important. And then one of the tools that we use a lot is buddying or pairing. So pairing might be specifically like this programming session, I'm sitting with someone else, we're working together. I'm not sitting here by myself guessing, hoping and then asking for feedback. And that feedback feels intimidating, because I don't feel like I even knew what I was doing, sort of thing. Like working with others is a great way to get that, you know, by osmosis, any way you want to describe it, or you know, someone who's actually good at coaching which is, you know, not everyone but... so some mix there. So, and then a buddy sorry, like very clearly identifying, even when you're not working together, this is someone who's responsible for making sure you have what you need. Because even in a team of six or eight can be a little bit intimidating, and this is whether you're, you know, went to MIT for CS or whether you have some totally different background, you still feel intimidated, like, do I belong here? Do, you know, do I have the skills that all these other people have? So having someone specifically identified instead of just shouting into the void or sort of hoping that someone's going to come and help you, I think is really important. So so much of it to me, to kind of put a bow on that, is building the support systems for someone to succeed. And then the, okay, these are the tools you need, comes naturally, right? Meaning, making them comfortable, giving them some sense that they're contributing, that they have value to the team, like, they wouldn't be there if they didn't, but people don't always feel that way when they show up, and then identifying with them, okay, this is an area you want to learn, you want to work on, here's a project, we can work on this together, probably a small project so we can get some momentum, get something out, you know, shipped, like ultimately feeling that momentum, feeling like you're contributing is the goal. And, and so identifying ways, it's a lot easier for someone in a management or senior role to identify where those opportunities are, assess that they're appropriate for someone new who's trying to learn, then to have that new person look at, you know, a bunch of things that need to get done and be able to say that one looks like it's probably at my skill level, like that's really hard for someone new.
Adam
Well, this has been an absolutely fascinating discussion, but sadly, we are out of time for this week's episode. Our thanks to CircleCI CTO Rob Zuber for joining us though.
Rob
Thanks so much for having me. It's really interesting.
Connor
You can find links to all the topics we've spoken about today in the show notes and even more on our website at itpro.co.uk.
Adam
You can also follow us on social media as well as subscribe to our daily newsletter.
Connor
And don't forget to subscribe to the IT Pro Podcast wherever you find your podcasts. And if you're enjoying the show, leave us a rating and review.
Adam
We'll be back next week with more analysis from the world of IT, but until then, goodbye!
Connor
Bye.
