Building an Engineering Recruitment Process that Candidates Love with Alan Spadoni

Ledge: Alan, welcome! Thanks for joining us. Tell us about yourself. Tell us your story.

Alan: Thanks for having me. I’m currently director of engineering at Buildout which is a small startup in the commercial real estate space. They were looking for some help with managerial tasks. The CTO is a great developer, a great technology guy, and a great idea guy but he didn’t have enough time for the management stuff. So I jumped on board to help out with that.

They were originally hiring for a manager position but I sort of talked them into thinking about this at a larger scale of growing a team and growing the organization and also sort of growing our tech presence in Chicago. That’s why the title is what it is.

Before this, I was at Groupon for six and a half years with almost four years in which we were doing software engineering management where I learned a lot about my trade. They did a great job with managerial training there and just working in a huge scaled environment with different engineers and different teams. It was a really good starting experience for helping me to grow my career.

Ledge: Fantastic! Off-mic, you and I were talking about it being a challenging hiring environment. There’s a crazy demand for engineers pretty much across every market in the U.S. and even globally in some instances.

We we’re talking about it from a recruiting standpoint. How do you make your company stand out for people coming right out of school and internships and building that pipeline?

And I thought you had some interesting insights to share on how you make an engineering culture in a way that productizes the culture so you’re not just another listing on the job board.

Alan: Obviously, we in Chicago don’t quite have the tech culture that Silicon Valley and the West Coast do. We saw the major presence from a lot of the big companies and I am also hiring against my former employer a lot of times plus we are a Rails shop. We do some React but we’re primarily a Rails shop; and that’s also hiring on not the current tech way. If you’re looking for JavaScript engineers or if you’re looking more for enterprise Java engineers in Chicago because of the trading presence, you have a much larger candidate pool.

Rails, not so much. It’s either people who haven’t done it in a couple of years or it’s a very small pool of people who are still actively Rails developers.

There’s quality out there and there have been engineers but it’s definitely tough. Qhen I started where you couldn’t walk on the street without falling over a Rails engineer looking for a job.

You also have a lot of bootcamp grads who learned Rails which is great. A lot of times, those candidates will really work out but we do have to be careful because, a lot of times, definitely a major thing I want to avoid is bringing in someone or screening someone who just doesn’t meet the bar at all because I want them to have a good experience and that’s really hard to make a good experience.

There are a couple of areas I focus on when doing this.

The first is making sure that from start to finish, they have a great experience; and I kind of touched on this a minute ago. What this means is that from start to finish, we contact the candidate quickly; we get them in the pipeline quickly; we address their concerns quickly. We don’t make them wait around for an answer. We don’t have an eight-part interview that takes six weeks.

A lot of what we see from other companies, especially larger companies, they just have a long turnaround time because that’s a way more pleasant experience.

I’ve had friends who have talked about this. It’s just miserable because you don’t know where you stand; you don’t know what’s going on; you haven’t gotten an answer yet. You’re emailing people and you’re not getting anything back.

We definitely don’t want that. And that’s something we’re working at getting better at. But I think we’re already pretty good. We’ve already heard from people that our experience is good and we’re also starting to get a little bit of local buzz around, “Hey, I’ve heard that you, guys, really are good at your interview process.” That’s a major thing.

The other thing is making sure that our interviews are targeted enough to where we’re testing the multiple areas of expertise. We don’t do brain teasers. We don’t do FizzBuzz. We don’t do things that try to make the interviewer feel.

We do things that are actually novel problems but they’re related to what we do. We heavily test for problem solving. We heavily test for wanting to get what the candidates have done. We test for common design pattern-type stuff like things that you’re going to use in the job.

It’s also interesting that you mentioned earlier that college recruiting is tough, and it is. But one thing that our CTO came up with

─ we went to the bank and we got $2000 dollars in singles which is a lot harder than you’d expect; that’s a really strange request. The teller was actually ashamed; she said, “I’m sorry. We don’t have two thousand singles.” So we had to go to another bank to finish it off.

We tied those with a Buildout logo, like a little band; and we put them in a huge sack. And we went to college career fairs, for candidates who were looking for the premium swag, the really interesting good candidates that we talked to, we handed them cash

.

I’d say that probably 25% of candidates were like, “No, I’m not taking this. Should I take this? Is this legal?” but the rest of them were pretty happy with it. And we actually got a pretty nice response. We were next to Foxconn at one of these meetups and we were actually competing with them for a line for a little bit because people heard about this.

And, also, amazingly, we were not kicked out.

Ledge: So you just gave them the stack of cash. How much per candidate?

Alan: Ten dollars per candidate. It’s like a piece of swag but it’s more memorable than a t-shirt or a water bottle.

Ledge: That will certainly get your name out there. That’s one way to do it.

Alan: That’s our interview process. And then, obviously, once somebody starts here, we want to make sure they continue to have a growth path and they feel empowered to do their jobs and that we’re inclusive and considerate and that we’re telling them the truth, all the normal things you’d want in a job.

Our recruiting pipeline ─ you’re still recruiting your developers when they’re working here; you’re always in sort of a recruiting phase ─ is always good so that we get good recommendation; we have good Glassdoor reviews; people know us in the community. We sort of drive our employer brand passively just by having a really respected presence.

Ledge: How do you balance the idea of “I’ve got to grow fast,” growth that’s important ─ as a company, we have that growth mandate ─ along the lines of “Hey, I have to maintain a great culture”?

It’s easy when you have four people that you know really well; it’s not as easy when you’re thirty or a hundred or two hundred, five hundred. It starts to get diluted there.

What kind of thinking have you, guys, done on the leadership team from that angle?

Alan: One of the main things that I’ve tried to do is hire top-down experience wise. I try to hire senior developers, lead developers and architects before I start filling in the junior positions.

We’re trying to scale our team right now not quite to that hundred-developer level but we are trying to scale it up. We have twelve developers now and we’re trying to, at least, double that, if not, more.

I’ve hired two seniors so far and that allows me to have the freedom to start filling in the mid-level and the junior positions because what I try to make sure is that everyone has someone who is experienced and knows how to build their responsibilities and knows good work and development patterns and have the answers for the questions that they have.

Obviously, I’m here for that as well but I can’t pair with everybody. And then, there are also concerns around how to scale a team. We’re in the process of splitting to smaller teams at this point that are domain owners instead of just having one big model like an engineering team.

And then, making sure that those teams have leaders who are responsible and thoughtful and who make good managers even if they’re not directly in manager titles is also really important to me. That’s definitely something I look for in my senior engineer candidates.

Ledge: Obviously, we’re in the business of very senior engineers and also fully remote. I wonder, how do you, guys, deal with remote versus on-site? The second part of the question I like to ask everybody is “What makes the best senior engineer? What are the heuristics that you use to determine that?”

Alan: Your first question is on how we deal with remote employees. Example-wise, I have two right now. One is a developer who worked here for a year and a half before he moved away. Normally, we weren’t looking at remote candidates too often but he just had such a sustained pattern of excellence. We knew that if he were working remote, there would be no problem. And that’s definitely held true.

We bring him in once a month for a team outing to sync up with everybody just so he still has that personal touch. We also have a robot in the office which allows you to dial in and control it. Just move it around the office so if you want to go over someone’s desk and ask him a question, you can do that and just about everybody in the company has access to that robot.

My hope is that, one day, we’re all remote; we just have a hundred robots in the office with people riding around with the robots and maybe we set up some obstacle courses or races, get a little betting going on.

Ledge: That sounds like a very engineering culture.

Alan: The second employee is a contractor we hired from outside the company. He’s in Canada. He doesn’t come in his office. He was just here for a Halloween party and that was the first time he met everybody. We had a Halloween party with a live band karaoke. Everybody was there. And he really loved it. He got a chance to meet us all face to face in a more relaxed environment, get to really know us. He spoke with our contact at his consulting company and he said he was gushing about the opportunity.

I felt really good to get him involved. We try to get him involved in everything we’re doing. The last thing I want is for him to feel like a second-class citizen because he’s a contractor.

Ledge: That’s really important. We tell all our clients that.

“Hey, this is just a different way to get some talent on your team that you couldn’t find in another channel and you ought to treat them just like you treat every employee. Don’t hold them at a distance. Imagine that you need to segment off work. These are professionals and they know how to join into a team remotely. And you can probably learn a bunch of things from them because they have more experience in it than you do.”

Alan: It’s been great so far. He came in hitting the ground running. The great part about hiring a consultant is there’s no ramp-up time; there’s no lead-up time; there’s no pipeline building; there’s no much different situation than a full on-site a lot of times. They’re used to this work flow and they’re motivated so they know to get up and running really quickly. So it’s been great.

Your second question: The way we structure our interview problems is so that they’re tiered. We expect that a junior fresh grad candidate will be able to do with certain of things, probably algorithmically and computer science-wise pretty strong and not so much on app development just because that’s not really a highlight.

Maybe you have one or two classes if you’re in college and you’ve covered a little bit if you go to a bootcamp. But, obviously, you’re so spread out in that area that once you finish the bootcamp, you need to find the focus areas to pick and drill in on them so you continue to increase your knowledge.

As you move up, we start recognizing that you’ll be more familiar with design patterns; you’ll be more familiar with app development.

You might be less familiar with certain algorithm and computer science concepts just because you don’t use them as much anymore. But, mostly, you’ll have developed a really good sense of problem solving. You’ll be able to not only quickly implement solutions from experience but you’ll also know how to look up the problems you want to solve. You’ll know how to ask the right questions and you’ll start breaking the problem down so that instead of just diving in and starting to code, more senior developers will be like, “Okay, let’s write this down; here’s what I need; here are my requirements.”

It may not even be TTD or BDD just because you don’t use that interview but you’ll have some sort of prep steps where you break the problem down so that you’re able to hit on the edge cases quickly and you’re able to hit on quickly and you don’t code yourself into a corner.

And that usually only comes with experience. I think, sometimes, you can find candidates who can just sort of brute-force that stuff with intellect; but, as seniors, we’ve been in the trenches so much that we recognize these patterns right away.

Ledge: And what do you do on soft-skills front? Obviously, you’re going to expect these people to be great team members. They’re going to be mentoring, team coding, probably having to communicate more on if not an executive level, like a managerial level regardless of where they actually have people work for them.

How do you test that stuff out?

Alan: We have a couple of stages in our interview. Our first stage is always with the HR recruiting rep. They test for soft skills during that part of the interview as well as interests.

Then, in your phone screen, the first half of it is going to be soft-skill related; it’s going to be talking to your résumé. It’s going to be what questions you have about Buildout. It’s going to be how you respond to our culture, our stated team goals, our benefits, our team culture, and all those things.

Then, we also try to build some questions in there as well. It’s a tight timeline but we try to build some questions in there just to kind of get to not only “Can you speak technically to the work that you’ve done?” but also “Who did you work with? Was it cross-team functional? Did you mentor anybody? Were you mentored by anybody?” ─ just sort of the normal steps that happen during the lifecycle of the project.

If someone has a senior-level candidate and they’re mostly just coding on their own and they’re not really working with too many other people, then they may not be the right fit for us. The same thing goes if we see some flags about things like negativity or kind of talking past each other and things like that.

Then, on the on-site, the first thing we do is we have a lunch to meet and greet some of the team members so you don’t have to jump right in immediately to being tested on coding. You get a chance to eat and get to know us.

We try not to make that an interview but that’s a little bit of the soft skills. Different engineers test different areas of expertise. So it depends on who you’re interviewing with. But I always interview and the CTO always interviews. And during our problems, we have to cover pair programming and we have to cover how well they take advice and we have to cover a lot of the soft skills that we look for.

We try to build it in to the interview so it’s not super obvious like “Tell me about a time that you were challenged so much that you wanted to give up” or something like that. We just try to build it into the course of their interview.

If the candidate is sort of not speaking or not taking suggestions well and we see them going down a path that we’ve seen before that’s a wrong direction, those are the sorts of things that key us in.

So far, it’s been really successful. I have to say and this may sound bad but this is the easiest managerial job I’ve had because everyone works so well together that part of your job as the manager is conflict resolution. There have been some instances of it but it’s really just been smooth.

Ledge: And do you trace that back to the very rigorous hiring to keep the negativity at the door?

Alan: Yes. I think that’s a huge component of it. I think it’s also sort of the culture of the company as well. One of the first things I noticed here ─ and people have said this as well; someone who just started recently wrote a long email about this ─ is you can be yourself here. There are no masks and there is no checking who you are. Everybody is their authentic self and I find that to be really rare. I think it’s something that’s really good about working here.

I’m not taking credit for that in any way but that’s definitely something I really try to highlight to candidates.

Ledge: That’s fantastic. Do you, guys, use any kind of assessments, cultural or personality work style? Any of those types of tools to help balance out the team in the hiring?

Alan: No, we haven’t looked at any of that yet. That’s something that’s on our minds. Obviously, this is a never-ending refining process so my first step was to standardize our interview process and to make it easy to provide feedback and provide consistent feedback and provide unbiased feedback as you can get based on the way that I formulate the questions for each section of the interview that you’re running.

The next step is to start working on those sorts of things like diversity in all areas, whatever category you want to talk about.

Ledge: There are tons of body to work around it and all different choices. We did a little work on our side with the strengths finder just to look at it and go, “Wow, this is cool. We have different strengths in the team and here’s where we’re the same and here’s where we are different.” And we found it to be useful talking points. It can be a great tool.

Alan: That’s really interesting.

Ledge: Fantastic! Alan, it sounds like you’re doing awesome stuff. Congrats to you and the Buildout team and we’re happy to be on your radar doing the same stuff that you are.

Alan: Thank you.