Beth Andres-Beck is a senior software engineer at the Long-Term Stock Exchange. She is a full-stack developer, having written code for everything from HTML5 hybrid mobile applications to GPU-accelerated computer vision software. Her passions include mentorship, game theory and participating in cultures that sustainably build great software. Prior to LTSE, Beth worked at Hillary For America, Twitter and TripAdvisor.
Beth shares her experience with Hackbright on recruiting and interviewing bootcamp grads. Follow her on Twitter at @bethcodes.
With a candidate straight out of bootcamp, what I’m actually evaluating is how long I think they are going to be under my mentorship before they will be a net-positive. That number depends a lot on what we’re trying to do and who is available to mentor. I am confident that I can teach almost anyone how to program, so the question I’m trying to answer in an interview is how much time it is going to take and how positive the experience is going to be, for both of us.
As an interviewer, I look for signals on how fast the developer will incorporate feedback:
- Can they write code iteratively? Do they verify that each step works before moving on to the next step, as opposed to trying to plan everything up front and get it right the first time? (The second approach doesn’t scale to larger challenges as well as the first, and shorter feedback cycles let people learn faster.)
- Do they ask questions if they don’t understand something?
- When told a better way to do something, say that they understand and agree that that way is better, do they then do it the better way the next time it comes up?
- Do they have an aesthetic opinion of code? Do they care about the code they write? Can they tolerate writing ugly code until they find a better way?
- Can they express their decisions in terms of trade offs? People who think there is one right answer will have a harder time learning and adapting.
- Do they stick with a task, trying different ways to achieve it, even if none of them are right? I prefer that to either continuing to do something that isn’t working, or abandoning the task and giving up. Persistence is an excellent virtue in a programmer.
- Do they seem to enjoy the process of getting something wrong, and learning from it? (This can be hard to judge in a high-stress situation, so I ask questions about problems they’ve encountered to see if they have had that experience in the past).
Then I look for signals on how well they would collaborate here:
- Can they express themselves concisely, or do they ramble?
- Do they treat everyone they meet with respect?
- Are they willing to compromise their own opinions for the sake of consistency?
- Are they able to work under our cultural values? (At my current position, for example, those values include proactively seeking out diversity in recruiting, iterative product development and reasonable work-life balance. Someone who wants to feel like their job is their whole life, wants project specifications to be created up front or who values meritocracy over diversity will be a better fit at a different company.) This is the dreaded “culture fit”, but by articulating those values in specific terms it isn’t a generic catch-all for “do I like this person?”
- Can my company provide what they are looking for and avoid anything they hate?
Only then do I look for particular skills. I’m trying to figure out if a programmer can:
- Read code in whatever language they know and express opinions about it
- Write a function performing a simple iterative loop in a browser code environment
- Describe code they have written
- Find a problem by running code and somehow identifying which piece is failing (using a debugger, log statements or writing tests: I don’t care which, but bonus points for useful tests.)
- Name variables meaningful names
- Break down a mid-sized problem into a series of achievable steps
The challenge is that it is almost impossible to judge these things by looking at a resume. I can either have an inside line on the bootcamps to get recommendations from someone who knows my style and what I’m looking for in a candidate, or I have to actually talk to basically every graduate at a bootcamp recruiting event. Oftentimes I end up filtering largely arbitrary criteria just to try to make the problem manageable. I try to signal things that I think are important early and openly, because if candidates who won’t thrive in my company weed themselves out without losing the candidates who will, it saves both of us a bunch of time.
As The Interviewer, Ask *Relevant* Questions
The important thing is to figure out how well a candidate is going to do in the specific situation, rather than trying to judge them on some absolute scale. What kind of support a particular company has available for boot camp graduates and which skills are important for someone to be successful at a particular organization are related questions.
Quite often, companies haven’t thought through the actual tasks involved in the jobs they are hiring for, which makes evaluating candidates extremely challenging. If we don’t know what is important for success, we can’t judge whether people meet that criteria.
When I’ve worked to redesign interview processes, it often starts by sitting down and asking developers what they did that morning.
It almost always includes writing a little code, reading a bunch of code, debugging existing code, and then either chatting on Slack, sending emails or sitting in meetings. Then these companies want to go and interview the people they are hiring on how well they compose algorithms, when ~0% of their work time is spent on that.
I do want people to be able to write code (not algorithms, but a basic for-loop with varying behavior), but I also like to see them approach some code they aren’t familiar with and see how they read it, which questions they ask, whether they have opinions about, what feels pretty and what feels messy. I love getting intern-level code reviews: one of the values to me of working with junior developers is that they give me feedback I can’t get from others who have become inured to the problems of our languages.
As The Hiring Manager, Set Up The New Hire For Success
I always want an interview process that a programmer who will enjoy working at my company will come out of feeling excited and energized to join my company. I want them to know what the work and team dynamics are going to be like, and have a chance to decide if that’s what they are looking for. The more I can make the interview process match our day-to-day work, the more likely it is that we will be able to find a mutual fit.
For more advice on interviewing and recruiting from engineering bootcamps, click here.