Sep
28

Case Studies in Apprenticeship Vol. 4 — JC Grubbs and Dayton Nolan

Time to Read:

This is the fourth installment of a series (1, 2, 3) about successful apprenticeships. This time I’m talking to JC Grubbs and Dayton Nolan of DevMynd, a Chicago- and SF-based software consultancy. As an industry, we can’t rely on our old tactics to hire a diverse and skilled team anymore. By highlighting the successes of apprenticeships in the community, hopefully we can overcome the perceived barriers other companies have to starting their own programs.


Joe: Thank you for taking the time to come talk to me. First question, can you tell me a little bit about yourselves?

Dayton: Sure. Hi, my name’s Dayton Nolan. I’ve been programming professionally for about seven years now. I started as a frontend UI developer, and sort of graduated slowly to the backend, and what they all call the Full Stack Developer now. So I’ve been doing a lot of Javascript, API ruby backend kind of stuff. Mainly frontend because Javascript is my wheelhouse. I also manage the apprenticeship program at DevMynd.

JC: I’m JC, I’m the CEO of DevMynd, my background is as an engineer. It’s sad but I started in 1999. So that dates me a little, I’m an old guy now. When I walk into companies and a lot of our clients, I see all the 23 year old developers and feel ancient. Anyway, I started the company about four years ago now with the goal of putting a different spin on software consulting.

Joe: So what inspired you to start an apprenticeship program within a software consultancy?

JC: I had just seen it modeled really well a few times. Before I started DevMynd I was with a company called Obtiva which was purchased by Groupon back in the day. And apprenticeship was one of their big things, and I think they always had at least one or two apprentices on staff. David Hoover was one of the principles there, and obviously he’s big into apprenticeship. So when we started the company, it was a good way to grow the team, and teaching has always been in our DNA.

Dayton: In general, I think it’s a problem for anyone in the software industry. It’s supply and demand, and it’s tough. So I think people are increasingly looking toward mentoring their own devs because there just isn’t a lot of senior talent that isn’t already in a job that they like.

Joe: Do you find that there are new challenges in doing this in a consulting company, versus say a product company? A lot of the companies that I’ve seen are really product companies.

JC: I think for me, our experience and our talent is the thing we’re selling. We’re selling a solution to a problem that’s backed by really solid people. The ability to grow the team at the junior end, with hand-picked people who have more potential than skills, adds a lot of value to the team.

It gives us the ability to control and shape how people are developed. On the practical end of things, it lets us control the costs of the company by having junior folks. But the company gets a ton of internal value by doing this. People love sitting down with the apprentices and teaching them something. I think it helps us reaffirm old knowledge all the time. And having people who don’t know all the solutions makes us re-think and re-imagine solutions, not just groupthink the same solutions over and over again.

Dayton: Yeah, it’s a sort of the “our strength is our weakness” answer is that being a consulting company we have a varying array of projects going on in the shop at a given time. And at times that’s an advantage because we can expose an apprentice to a lot of different stuff. At the same time, it may or may not align with what that particular apprentice or candidate needs at a given time. So that can be a challenge for us to say “well, this person needs to learn this kind of thing.” Luckily nowadays there’s a variety of projects in the shop, so it’s increasingly less difficult to get people into the right kind of project to learn. But that can also be a challenge too, because depending on where the apprentice is at, you may not have exactly the kind of exercises. So sometimes it’s a matter of finding some way to modify a task in order to exercise those weaker muscles.

Joe: I want to know a little bit more about it. It sounds like the apprentices are learning via a project that they’re on, as part of a complete project team?

Dayton: Yeah. One of the things we’ve learned, we figured out, is that the most beneficial time spent for an apprentice is pairing. Pairing with a senior dev. And almost at that point, pairing with almost any other dev, even a previous apprentice or a junior dev. You learn so much more being steeped in an actual problem, as opposed to the concept of a problem. And if you have a good pair, they’re thinking out loud about how they’re thinking about the problem, how they want to solve it, the things they don’t know.

One of the things that immediately most apprentices will say is that they’re amazed that nobody is a magical genius, and they actually have to figure things out too.

Dayton: And they’re like “oh, you mean you don’t just know everything?” And we have to be like “no, I know a set of steps to get me where I’m going.” And I think that’s the first thing that most apprentices get is that we don’t know everything.

Joe: There’s this assumption that if you’re maybe five years into your career that all of a sudden complete solutions spring forth from your head.

Dayton: Yep. So, pairing is absolutely the way to level somebody up quickly. That being said, I think the challenge is getting someone paired up on the right thing at the right moment. So to augment that, they have a personal project. Something where the problem space is not a big question mark, or it’s not something new to them. It’s a passion project. It’s also a place where they can kind of make a mess and nobody’s on the hook for it. So we split about 80/20 just to give them a space and say, “go ahead and work on your personal project. Get it as messy as you need to.” But you also have the strength of the team. You can say “oh, I’m trying to do X, Y and Z.” And they get the benefit of the whole team.

And if you don’t leverage your experience, one thing we want to avoid with the personal projects is having them go off in the corner, and play with some crayons, and nobody ever interacts with them.

Joe: See you in six months!

Dayton: Yeah, and so what we hope to give them with that is to let them cut their teeth. And a lot of times what ends up happening is that they’ll be doing something during the week with their project, and they’ll go to their personal project and want to try it. In maybe a half-faked application they have. It’s an experimentation sandbox.

JC: With personal projects we make them build that project from start to finish. They have to come up with the idea, they have to write all the user stories for it. They have to pick architectural direction. Obviously the rest of the team does code review, but it’s really theirs to run how they want. And that gives us an interesting lens that we typically don’t get when they’re on a client project. How does this person behave when they’re alone? Do they go down rabbit trails, or stay laser focused on delivering the next thing? There’s a little more teaching that happens there that’s more directed than the sort of osmosis that happens when they get paired up with an existing team.

The other thing we like to do is put them in front of clients. They’re in our regular iteration planning meetings, and our daily standups with customers, right from the get-go. Because again, as a consultancy — that really values client-facing people — we have to train them on those skills as well. Those skills are often a little bit more subtle, and difficult to teach than the coding side of things.

Dayton: And I think that’s one of the things that really sets us apart in our program from a product company — or at least in my imagination I suppose — is that we need a lot more out of them, and a lot of times being a solid technical person is just plain not enough. And I’d argue that’s the same whether at a product company or not. But a lot of times what makes a dev an extremely great dev is knowing how and when to push back. Knowing what to give in on, and what to stand firm on. Knowing that when a client says X that they mean subtly Y. And it’s those ephemeral kind of skills that you can’t get. You need to learn the technical basics, but…

Joe: It’s almost easier to teach the technical basics.

Dayton: Oh yeah, clearly. Because that other stuff is so subtle. And even our experienced devs — and myself — learn that on projects all the time. “Oh, I shouldn’t have said that like this to this person, because it caused this emotional reaction I didn’t want.” But the message what exactly what I wanted to say, but you have to find the right envelope. If you’re just technical, and you approach it like “no, this is the right answer, and you agree and implement.” Instead of being like “he took that the wrong way, and he’s disagreeing with me, not because he disagrees with this particular technology, but maybe because of how I delivered it.” And maybe I didn’t even mean to sound this way or that way. So there’s all kinds of interpersonal things that come into play day-to-day, you have to go down a path to really exercise the hard stuff, which is the interactions.

They’re doing real client work. So they have a kind of a sandbox, but it’s also the real world.

Joe: So how do you evaluate that they’re done with the apprenticeship? I read that your apprenticeships last something like 3–12 months?

JC: Yeah. And I know that’s a huge swing. *laughs* We’ve seen some apprenticeship programs where there are very defined phases and a duration to it. It’s a little more regimented. For us, the sort of litmus test is really: can this person take a story and deliver it from start to finish on their own. It’s pretty basic. We don’t ask that they have to be able to do an entire project by themselves. They just need to stand on their own effectively with very little micromanagement.

Which is a fuzzy, hard to nail down kind of thing. We do have some measures. We’ve got maybe twenty or thirty things that we tend to look at.

Dayton: It’s more or less, you eyeball this list of traits that we see in a developer. And there’s a lot of things on that list, and a lot of it has to do with the day-to-day business of being a consultant, and not so much about the technical aspects.

JC: And another big thing that I’m realizing just now, is that the ideal candidate really needs to control their own learning. We are the tree that the moss grows on, right? But the apprentice has to actually make that happen themselves.

Dayton: We’re the bigger pond. You go to your bootcamp school, and you’re there to grow, and we’re the bigger pond you can throw yourself into in order to really grow and learn from people with a lot more experience.

JC: And we don’t throw people right into the deep end and ask them to stand on their own. We create a low…

Joe: Go for a water metaphor!

JC: Hah, yeah. I don’t have one ready. But it’s an environment where you really can mess up. You can go a little bit slower than everybody else, and that’s okay. And when you get stuck on something, and you need a little bit of extra help on a particular concept, we’ll find a way to help on that.

But the apprentice really needs to be in control of their own destiny a little bit. We’re not the kind of environment where you’re going to just follow a bunch of steps, and check off a bunch of checkboxes, and get somewhere at the end. And I think that mirrors the way we run our projects with clients. That’s what we expect of everybody, so we just expect the same thing from apprentices on a smaller scale.

Dayton: And we get similar feedback. The second thing that usually excites our apprentices is that they’re going to be working with real projects. They’re doing real client work. So they have a kind of a sandbox, but it’s also the real world.

Joe: Is there anything that strikes you as being not what you expected when you started these apprenticeships. I know JC you were already exposed to this stuff at Obtiva, and Groupon. But I find that things are really different once you jump into a program of your own.

JC: I think honestly the biggest thing for me was realizing that you can’t just teach them the technical things. Our first apprentice needed a lot of help on the soft skills and being a professional in front of clients. And I don’t think we did a tremendous job on helping him with that.

So, coming to the realization that we have to pick candidates that don’t need a lot of help on that, or be willing to give them that kind of education. That was for me the biggest thing.

Dayton: Yeah. For me maybe the biggest surprising thing is that less structure… I thought “oh you do this, and then you do your ‘X’ skills, and then you learn your ‘Y’ skills, and then you learn your ‘Z’ skills.” And learning that letting them pair, sort of free-form, even though it feels kind of hectic and chaotic, it’s much more beneficial for them to see what it is.

Like JC said, if they’re autodidactic. If they’re learning on their own and doing their work, then we don’t have to manage that. But exposing them to the right things leads them to go home and to go off in the right directions when they’re doing their own learning. So the big surprise was not having to have a regimented list of things they need to learn to be a good developer.

You take someone who you already know is going to be a good developer, and you provide them with the environment to grow faster. We’re almost like an accelerator. We don’t take someone from A to B. We take someone who’s headed to B, and we put them in a race car.

If your interview process is selecting to know SQL, and you know this, and you have five years of experience, then you’re going to get a very homogenous team.

Joe: Great. Last question: Is there something that you’d want to tell companies that are thinking of starting an apprenticeship, but can’t really get over that hump to get started?

Dayton: I would say, it’s supply and demand. How easy is it for you to hire a developer, let alone a senior developer. And talking about cost. You want a talented senior developer, well at least for now they get to write a blank check. If you want that really solid developer, you’re going to pay for that. Whereas you can grow your own talent pool, and they can grow with you. Instead of always having to go out looking and competing with other companies for this talent. You can foster your own creative center and grow what you need.

JC: I would say, go slow. Even if you’re a giant dev shop, start with one person. I think we’ve had one time where we had two apprentices simultaneously. I thought we would do that more frequently. And I actually find myself stepping back. We’re a team of 20 people, so we’re only able to take on one person at a time and give that person the attention they need.

So I’d say start slow. And the other thing I’d say is for teams that are struggling on the diversity front. Apprenticeship is a great way of starting to move to address that. We find that the gender and racial mix coming out of bootcamps and even universities is much better than the industry at large.

And so that’s one way you can start to move the needle for diversity. You have to watch out not to have all of your minority folks be on the junior end of your team, but it is one way to move the needle there. And sometimes it’s the only way to move that needle, if there just aren’t enough organic job applications. So if the team is struggling with that, it’s a big opportunity.

Dayton: And it also gives you an opportunity to get candidates who are probably excellent developers and are really great on product teams, but maybe aren’t so great on a technical interview. There’s a wide array of different types of personalities that work well with development, and in software, and you need a range of those. If your interview process is selecting to know SQL, and you know this, and you have five years of experience, then you’re going to get a very homogenous team. Not only from a diversity standpoint but from a skills standpoint. That can actually cripple your development process.

Joe: Well, thanks for taking the time to talk.

JC: Sure.

Dayton: Thanks.


JC Grubbs is the CEO of DevMynd. You can find him tweeting at @thegrubbsian. Dayton Nolan is a Consultant at DevMynd. He also tweets, at @daytonnolan. You can visit them during one of the many events they host at their space in Chicago.

Joe Mastey gives tech companies an edge in the talent war and is also a hired gun for software projects. You can watch Joe’s talks at Confreaks, and he has often twet at @jmmastey.

If you enjoyed this article, please share or recommend it so that more people can see it.

This is the fourth installment of a series (1, 2, 3) about successful apprenticeships. This time I’m talking to JC Grubbs and Dayton Nolan of DevMynd, a Chicago- and SF-based software consultancy. As an industry, we can’t rely on our old tactics to hire a diverse and skilled team anymore. By highlighting the successes of apprenticeships in the community, hopefully we can overcome the perceived barriers other companies have to starting their own programs.


Joe: Thank you for taking the time to come talk to me. First question, can you tell me a little bit about yourselves?

Dayton: Sure. Hi, my name’s Dayton Nolan. I’ve been programming professionally for about seven years now. I started as a frontend UI developer, and sort of graduated slowly to the backend, and what they all call the Full Stack Developer now. So I’ve been doing a lot of Javascript, API ruby backend kind of stuff. Mainly frontend because Javascript is my wheelhouse. I also manage the apprenticeship program at DevMynd.

JC: I’m JC, I’m the CEO of DevMynd, my background is as an engineer. It’s sad but I started in 1999. So that dates me a little, I’m an old guy now. When I walk into companies and a lot of our clients, I see all the 23 year old developers and feel ancient. Anyway, I started the company about four years ago now with the goal of putting a different spin on software consulting.

Joe: So what inspired you to start an apprenticeship program within a software consultancy?

JC: I had just seen it modeled really well a few times. Before I started DevMynd I was with a company called Obtiva which was purchased by Groupon back in the day. And apprenticeship was one of their big things, and I think they always had at least one or two apprentices on staff. David Hoover was one of the principles there, and obviously he’s big into apprenticeship. So when we started the company, it was a good way to grow the team, and teaching has always been in our DNA.

Dayton: In general, I think it’s a problem for anyone in the software industry. It’s supply and demand, and it’s tough. So I think people are increasingly looking toward mentoring their own devs because there just isn’t a lot of senior talent that isn’t already in a job that they like.

Joe: Do you find that there are new challenges in doing this in a consulting company, versus say a product company? A lot of the companies that I’ve seen are really product companies.

JC: I think for me, our experience and our talent is the thing we’re selling. We’re selling a solution to a problem that’s backed by really solid people. The ability to grow the team at the junior end, with hand-picked people who have more potential than skills, adds a lot of value to the team.

It gives us the ability to control and shape how people are developed. On the practical end of things, it lets us control the costs of the company by having junior folks. But the company gets a ton of internal value by doing this. People love sitting down with the apprentices and teaching them something. I think it helps us reaffirm old knowledge all the time. And having people who don’t know all the solutions makes us re-think and re-imagine solutions, not just groupthink the same solutions over and over again.

Dayton: Yeah, it’s a sort of the “our strength is our weakness” answer is that being a consulting company we have a varying array of projects going on in the shop at a given time. And at times that’s an advantage because we can expose an apprentice to a lot of different stuff. At the same time, it may or may not align with what that particular apprentice or candidate needs at a given time. So that can be a challenge for us to say “well, this person needs to learn this kind of thing.” Luckily nowadays there’s a variety of projects in the shop, so it’s increasingly less difficult to get people into the right kind of project to learn. But that can also be a challenge too, because depending on where the apprentice is at, you may not have exactly the kind of exercises. So sometimes it’s a matter of finding some way to modify a task in order to exercise those weaker muscles.

Joe: I want to know a little bit more about it. It sounds like the apprentices are learning via a project that they’re on, as part of a complete project team?

Dayton: Yeah. One of the things we’ve learned, we figured out, is that the most beneficial time spent for an apprentice is pairing. Pairing with a senior dev. And almost at that point, pairing with almost any other dev, even a previous apprentice or a junior dev. You learn so much more being steeped in an actual problem, as opposed to the concept of a problem. And if you have a good pair, they’re thinking out loud about how they’re thinking about the problem, how they want to solve it, the things they don’t know.

One of the things that immediately most apprentices will say is that they’re amazed that nobody is a magical genius, and they actually have to figure things out too.

Dayton: And they’re like “oh, you mean you don’t just know everything?” And we have to be like “no, I know a set of steps to get me where I’m going.” And I think that’s the first thing that most apprentices get is that we don’t know everything.

Joe: There’s this assumption that if you’re maybe five years into your career that all of a sudden complete solutions spring forth from your head.

Dayton: Yep. So, pairing is absolutely the way to level somebody up quickly. That being said, I think the challenge is getting someone paired up on the right thing at the right moment. So to augment that, they have a personal project. Something where the problem space is not a big question mark, or it’s not something new to them. It’s a passion project. It’s also a place where they can kind of make a mess and nobody’s on the hook for it. So we split about 80/20 just to give them a space and say, “go ahead and work on your personal project. Get it as messy as you need to.” But you also have the strength of the team. You can say “oh, I’m trying to do X, Y and Z.” And they get the benefit of the whole team.

And if you don’t leverage your experience, one thing we want to avoid with the personal projects is having them go off in the corner, and play with some crayons, and nobody ever interacts with them.

Joe: See you in six months!

Dayton: Yeah, and so what we hope to give them with that is to let them cut their teeth. And a lot of times what ends up happening is that they’ll be doing something during the week with their project, and they’ll go to their personal project and want to try it. In maybe a half-faked application they have. It’s an experimentation sandbox.

JC: With personal projects we make them build that project from start to finish. They have to come up with the idea, they have to write all the user stories for it. They have to pick architectural direction. Obviously the rest of the team does code review, but it’s really theirs to run how they want. And that gives us an interesting lens that we typically don’t get when they’re on a client project. How does this person behave when they’re alone? Do they go down rabbit trails, or stay laser focused on delivering the next thing? There’s a little more teaching that happens there that’s more directed than the sort of osmosis that happens when they get paired up with an existing team.

The other thing we like to do is put them in front of clients. They’re in our regular iteration planning meetings, and our daily standups with customers, right from the get-go. Because again, as a consultancy — that really values client-facing people — we have to train them on those skills as well. Those skills are often a little bit more subtle, and difficult to teach than the coding side of things.

Dayton: And I think that’s one of the things that really sets us apart in our program from a product company — or at least in my imagination I suppose — is that we need a lot more out of them, and a lot of times being a solid technical person is just plain not enough. And I’d argue that’s the same whether at a product company or not. But a lot of times what makes a dev an extremely great dev is knowing how and when to push back. Knowing what to give in on, and what to stand firm on. Knowing that when a client says X that they mean subtly Y. And it’s those ephemeral kind of skills that you can’t get. You need to learn the technical basics, but…

Joe: It’s almost easier to teach the technical basics.

Dayton: Oh yeah, clearly. Because that other stuff is so subtle. And even our experienced devs — and myself — learn that on projects all the time. “Oh, I shouldn’t have said that like this to this person, because it caused this emotional reaction I didn’t want.” But the message what exactly what I wanted to say, but you have to find the right envelope. If you’re just technical, and you approach it like “no, this is the right answer, and you agree and implement.” Instead of being like “he took that the wrong way, and he’s disagreeing with me, not because he disagrees with this particular technology, but maybe because of how I delivered it.” And maybe I didn’t even mean to sound this way or that way. So there’s all kinds of interpersonal things that come into play day-to-day, you have to go down a path to really exercise the hard stuff, which is the interactions.

They’re doing real client work. So they have a kind of a sandbox, but it’s also the real world.

Joe: So how do you evaluate that they’re done with the apprenticeship? I read that your apprenticeships last something like 3–12 months?

JC: Yeah. And I know that’s a huge swing. *laughs* We’ve seen some apprenticeship programs where there are very defined phases and a duration to it. It’s a little more regimented. For us, the sort of litmus test is really: can this person take a story and deliver it from start to finish on their own. It’s pretty basic. We don’t ask that they have to be able to do an entire project by themselves. They just need to stand on their own effectively with very little micromanagement.

Which is a fuzzy, hard to nail down kind of thing. We do have some measures. We’ve got maybe twenty or thirty things that we tend to look at.

Dayton: It’s more or less, you eyeball this list of traits that we see in a developer. And there’s a lot of things on that list, and a lot of it has to do with the day-to-day business of being a consultant, and not so much about the technical aspects.

JC: And another big thing that I’m realizing just now, is that the ideal candidate really needs to control their own learning. We are the tree that the moss grows on, right? But the apprentice has to actually make that happen themselves.

Dayton: We’re the bigger pond. You go to your bootcamp school, and you’re there to grow, and we’re the bigger pond you can throw yourself into in order to really grow and learn from people with a lot more experience.

JC: And we don’t throw people right into the deep end and ask them to stand on their own. We create a low…

Joe: Go for a water metaphor!

JC: Hah, yeah. I don’t have one ready. But it’s an environment where you really can mess up. You can go a little bit slower than everybody else, and that’s okay. And when you get stuck on something, and you need a little bit of extra help on a particular concept, we’ll find a way to help on that.

But the apprentice really needs to be in control of their own destiny a little bit. We’re not the kind of environment where you’re going to just follow a bunch of steps, and check off a bunch of checkboxes, and get somewhere at the end. And I think that mirrors the way we run our projects with clients. That’s what we expect of everybody, so we just expect the same thing from apprentices on a smaller scale.

Dayton: And we get similar feedback. The second thing that usually excites our apprentices is that they’re going to be working with real projects. They’re doing real client work. So they have a kind of a sandbox, but it’s also the real world.

Joe: Is there anything that strikes you as being not what you expected when you started these apprenticeships. I know JC you were already exposed to this stuff at Obtiva, and Groupon. But I find that things are really different once you jump into a program of your own.

JC: I think honestly the biggest thing for me was realizing that you can’t just teach them the technical things. Our first apprentice needed a lot of help on the soft skills and being a professional in front of clients. And I don’t think we did a tremendous job on helping him with that.

So, coming to the realization that we have to pick candidates that don’t need a lot of help on that, or be willing to give them that kind of education. That was for me the biggest thing.

Dayton: Yeah. For me maybe the biggest surprising thing is that less structure… I thought “oh you do this, and then you do your ‘X’ skills, and then you learn your ‘Y’ skills, and then you learn your ‘Z’ skills.” And learning that letting them pair, sort of free-form, even though it feels kind of hectic and chaotic, it’s much more beneficial for them to see what it is.

Like JC said, if they’re autodidactic. If they’re learning on their own and doing their work, then we don’t have to manage that. But exposing them to the right things leads them to go home and to go off in the right directions when they’re doing their own learning. So the big surprise was not having to have a regimented list of things they need to learn to be a good developer.

You take someone who you already know is going to be a good developer, and you provide them with the environment to grow faster. We’re almost like an accelerator. We don’t take someone from A to B. We take someone who’s headed to B, and we put them in a race car.

If your interview process is selecting to know SQL, and you know this, and you have five years of experience, then you’re going to get a very homogenous team.

Joe: Great. Last question: Is there something that you’d want to tell companies that are thinking of starting an apprenticeship, but can’t really get over that hump to get started?

Dayton: I would say, it’s supply and demand. How easy is it for you to hire a developer, let alone a senior developer. And talking about cost. You want a talented senior developer, well at least for now they get to write a blank check. If you want that really solid developer, you’re going to pay for that. Whereas you can grow your own talent pool, and they can grow with you. Instead of always having to go out looking and competing with other companies for this talent. You can foster your own creative center and grow what you need.

JC: I would say, go slow. Even if you’re a giant dev shop, start with one person. I think we’ve had one time where we had two apprentices simultaneously. I thought we would do that more frequently. And I actually find myself stepping back. We’re a team of 20 people, so we’re only able to take on one person at a time and give that person the attention they need.

So I’d say start slow. And the other thing I’d say is for teams that are struggling on the diversity front. Apprenticeship is a great way of starting to move to address that. We find that the gender and racial mix coming out of bootcamps and even universities is much better than the industry at large.

And so that’s one way you can start to move the needle for diversity. You have to watch out not to have all of your minority folks be on the junior end of your team, but it is one way to move the needle there. And sometimes it’s the only way to move that needle, if there just aren’t enough organic job applications. So if the team is struggling with that, it’s a big opportunity.

Dayton: And it also gives you an opportunity to get candidates who are probably excellent developers and are really great on product teams, but maybe aren’t so great on a technical interview. There’s a wide array of different types of personalities that work well with development, and in software, and you need a range of those. If your interview process is selecting to know SQL, and you know this, and you have five years of experience, then you’re going to get a very homogenous team. Not only from a diversity standpoint but from a skills standpoint. That can actually cripple your development process.

Joe: Well, thanks for taking the time to talk.

JC: Sure.

Dayton: Thanks.


JC Grubbs is the CEO of DevMynd. You can find him tweeting at @thegrubbsian. Dayton Nolan is a Consultant at DevMynd. He also tweets, at @daytonnolan. You can visit them during one of the many events they host at their space in Chicago.

Joe Mastey gives tech companies an edge in the talent war and is also a hired gun for software projects. You can watch Joe’s talks at Confreaks, and he has often twet at @jmmastey.

If you enjoyed this article, please share or recommend it so that more people can see it.

Tags: apprenticeship | case-studies-in-apprenticeship |

Recent Posts

Junior, Intern or Apprentice

What's the real difference between a junior developer, an intern and an apprentice?

Announcing chicagoapprenticeships.com

I'm creating a list of apprenticeships in Chicago, to help both companies and learners.