Finding the Right Fit (Avielle Wolfe)
I recently sat down with Avielle Wolfe from the thoughtbot New York offices for our podcast, Crossroads, brought to you by Upcase. We talk to experienced developers about how their experience has evolved, we ask them about pivotal moments in their careers, and what helped them take “junior” out of their title. Upcase makes it easy for you to take the next step. Upcase shows you how the best developers around tackle coding challenges, what their backgrounds are, and how they got to where they are.
What do you do?
Natalie: Avielle, could you do a little intro about what you do here and what your work involves?
N: Awesome, and how long have you been working here?
A: Three years.
N: And what were you doing before that?
A: I was in a bootcamp.
N: Oh really?
A: To learn Rails.
How did you learn?
N: I’m always interested in people who go to bootcamps, I’ve always been fascinated by that experience. What made you decide to go to a bootcamp and how did you find out about it?
A: I was working as a PHP developer, by developer, I mean intern. I knew almost no programming going into the job. I’d been doing that for eight months, and I was talking to a friend who was working as a more senior developer, and I asked him “What can I do to advance my career?” He recommended going to a boot camp and he recommended Rails. He’s doing Python himself, but he said, “Ruby is where the hot jobs are at right now, so find a Ruby bootcamp”.
Were you coding at school or in college?
N: So with the PHP internship that you were doing for eight months, take me back before that, where were you then? You said that you hadn’t done very much programming before that point.
A: Yeah, I had done a 101 course in university, and that PHP job was my first job out of university. I had been a Physics major and at some point I realized that that wasn’t the career path for me, but I wasn’t sure what else to do. So, I tried a little bit of a bunch of different things, and I had some computer science friends and we worked on a website together. I can’t say I was particularly helpful, but I did learn a lot and I liked what I was doing. I was in Boston, and it has a really large start up scene, so I applied to a ton of different start ups. I got very used to rejection, and then eventually there was one start up that I gelled with their mission. I love reading and I also write a little bit and their job was to connect self published authors with reading communities. Help them kind of start their career. So I liked the mission and ended up working with them.
I had been a Physics major and at some point I realized that that wasn’t the career path for me, but I wasn’t sure what else to do.
How important are mission, values, and culture fit?
N: That’s so interesting. So, do you think that finding a place to land where you can actually loved the mission was a crucial part for you to learn. Do you think that if you landed somewhere else, where the mission connection wasn’t as strong, you may not have learnt quickly?
I got very used to rejection, and then eventually there was one start up that I gelled with their mission.
A: Possibly. The mission connection was really helpful for me to stay passionate, but I think the bigger importance that it had was me actually getting hired. All the start ups are competing to hire developers and I don’t think someone as inexperienced as myself would necessarily have been hired if it weren’t for the fact that they were desperate for developers and they needed people who cared enough about the mission to work for not very much pay. I fit both of those: I was not a developer, but I was very interested in becoming one, and I really liked the company and its mission.
How did you negotiate along the way?
N: So, you’re in this situation where you’ve just got a great internship with a start up and a mission that’s very compatibility with both your interests and your values. You mentioned this idea of the demand for developers, but also the lack of budget at the beginning for a lot of start ups. What sort of advice would you give to yourself at that time, thinking about money? It’s really quite an uncomfortable thing to talk about for a lot of people, especially in an industry you don’t quite understand. It can feel as though you need to sign on the dotted line if you don’t know what’s out there. Is there any advice you’d give yourself going back to that time?
“…ask for more most of the time, and hold your line when you’re in the negotiation, and once you get back home, compare the different options that you have on the table and that’s the time to be realistic…”
A: I would say to ask for more most of the time, and hold your line when you’re in the negotiation, and once you get back home, compare the different options that you have on the table and that’s the time to be realistic and say, maybe this isn’t what I want but I’m breaking into a new field so it’s what I’m going to take. However, I wouldn’t give that perspective to the person that I’m negotiating with. I wish it wasn’t that way. I wish that every company I talked to, I trusted them to treat me fairly and give me what was a fair salary based on the company, but unfortunately I don’t think that’s the way a lot of companies are currently operating.
N: You think having a very pragmatic approach to negotiation, and having some things that your willing to be flexible on and others that you’re not willing to budge on is really important, outlining things before you go into the room to negotiate and applying that systematically across all of the interviews?
A: Yes. And something to keep in mind is, if you reach that negotiation point, normally that happens after you’ve had technical interviews and culture fit interviews. So they already want you if they’re bringing you to that point, so remember that when you’re talking with them.
What are technical interviews like?
N: Let’s dive a little bit deeper into technical interviews, because I think this is something that a lot of people are afraid of, and there’s a lot of myth around what a technical interview ought to be like, looks like, and is like and how to do well at a technical interview. There doesn’t seem to be a standardized practice around this, there’s some blog posts about some companies having very bizarre interviewing processes, and others having very boring ones. What does someone who is new to this field, as you were coming in from a Physics major, need to know about a technical interview?
“… if you reach that negotiation point, normally that happens after you’ve had technical interviews and culture fit interviews. So they already want you if they’re bringing you to that point, so remember that when you’re talking with them.”
A: You’re right that they do vary widely. You can have everything from data problems to helping to build a feature in an application, to white boarding some logic puzzle. It’s hard to prepare for all of that. I try to focus on preparing for the work that I’m going to be doing when I’m in the job itself, and then I look for companies that have interview processes that test that specifically. I like being able to pair with someone else on a problem during an interview, I like having questions that surround the technology that I’ll be using, so if it’s for Ruby on Rails, then that tests my understanding of Rails.
N: Do you think it’s important that you are being interviewed specifically for the tech stack that you’ll be on or the technologies that you’ll be using?
Can you spot curiosity in a candidate?
N: It’s no surprise given that we’re in a room called curiosity, that we are going to about this of idea of learning. How do you know that someone is curious, and how do you know that someone is capable of learning, or actively demonstrating that curiosity?
A: They ask questions. They want to know about what we’re doing. When I’m interviewing someone and we’re pairing, we might be working on a project that I’m currently working on, so what I do is, I have this bug, or this feature that I’m already working on and I bring somebody in, but it’s new to them. I like when they want to know about the project, when they want to know about the choices that I’ve already made with regards to the code that I’m writing. When they look to see, are there tests, what’s being tested, how are different parts of the app fitting together?
“When I’m interviewing someone and we’re pairing… I like when they want to know about the project, when they want to know about the choices that I’ve already made with regards to the code that I’m writing.”
N: Asking lots of questions shows that you’re curious and that you’re willing to learn. What can someone who’s interviewing do, before they’re in the interview space, to demonstrate that? Through their portfolio of work, or through their CV or other things, like projects that they’ve worked on? So let’s say I’ve come straight out of a coding bootcamp and I want a gig at a great consultancy, a software consultancy, or a start up, which you’ve done, what do I show on my CV to show that I’m curious and I like learning? Do I contribute to open source projects? Do I build stuff on the side? What do I do to show that I’m curious and I’m willing to learn?
A: All of that and none of that. When I’m at a job, and I’m not interested in leaving it anytime soon, then I’m not necessarily doing a ton of programming outside of work unless there’s a particular issue that I can solve using programming. Whether I’m automating something in my home, or whether I’m creating something because I have an interest in a social issue and technology can help there, but it’s not focused around just the desire to program. That’s what I’m doing 40 hours a week already. So I want to do other things with my life outside of work most of the time. That said, when it comes time to interview, companies are going to be looking for that additional work. And so that’s when I’ll ramp up and spend some evenings, and some weekends, creating personal projects that are really portfolio pieces. I make them look nice deliberately. They might not be the next Facebook, but they are something that showcases the work that I’m capable of doing.
“…when it comes time to interview, companies are going to be looking for that additional work. And so that’s when I’ll ramp up and spend some evenings, and some weekends, creating personal projects that are really portfolio pieces.”
How do you know you’re no longer a junior developer?
N: Any advice you would give to someone who has actually been a junior developer for quite some time, but doesn’t know whether they’re ready to call themselves an experienced developer, or a mid-level developer, or a senior developer? At what point do you make that transition? What does a developer who is not junior look like to you?
A: A developer who’s not junior can start an application on their own: they have their whole dev environment set up, they’re able to start an application, start building features, they know how to test, and they are comfortable looking things up when they run into a problem. They know how to go to documentation. They know how to search through stack overflow. They know how to read source code. They know how to solve issues on their own. It’s not that they necessarily are going to be as fast as they might be if they’re pairing with someone more senior, but they’re able to do it, they’re not going to just be stuck if they don’t have the opportunity to look for someone else for help.
N: Okay, interesting. So that’s a very technical definition of what not a junior programmer looks like, or not a junior developer looks like. Are there any sort of holistic elements that you’re looking for outside of the technical? You define all the (technical) competencies that you believe make someone transition from being junior to the next level. What other skills or competencies would you look for in their ability to collaborate with team members, or their ability to listen to client requirements, et cetera, et cetera?
A: They have an understanding of product, for one. They’re able to push back on product demands if they’re unreasonable, either with regards to deadline, or with regards to what users need. They have a general understanding of UX and what’s important and how to build a good web interface. They are able to mentor people who are more junior than they are, and they are able to have an opinion about the process of the team. So how they do an agile flow, when they have different meetings, whether they’re having too many meetings. They have an opinion about these things and they talk about it with their team mates.
[Non-junior developers] have an understanding of product [and t]hey’re able to push back on product demands if they’re unreasonable, either with regards to deadline, or with regards to what users need
What were the pivotal moments in your career?
N: One final question: if you look back on your career, what would you say were the pivotal moments for you, and the kinds of moments where you felt yourself step up in big ways? Whether it’s graduating, or finishing the bootcamp, what were your big stepping stones in your career so far and what did they mean to you?
A: One of the first, I think, was when I was still at that start up. We originally were building off of just PHP code, virtually no framework, just a bunch of files some thousands of lines long. I learnt what MVC was, because I wasn’t happy with the way things were currently structured. It was really hard to fix any bug or to add anything. Anything you added broke other things, because the code base was too monolithic, and too difficult to understand to avoid that. So I went and studied MVC and learned a PHP MVC framework based off of Rails called Laravel, and it’s was a start up so we were iterating on different products. Once I learned that, I built the new products in that, and I taught it to the other people that were working on the technical side of the company. And that was a big moment, because I had taken that onto myself. I had thought, okay this can be done better, does anyone have a way of doing it better? And they found out, “Oh we have a web development in general, has a better way of doing it, let’s do that”.
So that was one pivotal moment, and it was when I had done that and we had been working with that for a few months that I decided that I wanted to take the next step in learning and go to a boot camp. And with the boot camp I got lucky because thoughtbot taught it. So I was able to demonstrate my skills and my learning ability to them during those three months, which I think, made the interview process a little easier. I still went through the interview process, but they already had an idea of who I was, because they had been working closely with me for three months. That was another moment, and I’ve been here for three years. I was an apprentice first, which is a great program that thoughtbot has where I’m working on client work with a mentor and we’re not billing for my time. And it’s like another boot camp.
By the end of that, I had had six months of concentrative learning, and I went in as being billed as a full developer. It was a little intimidating at first, because I was around all of these more senior developers and I felt, okay I am just coming out of school essentially, and I need to measure up to them. For a while it was hard for me to ask questions, because I didn’t want to show when I didn’t know things. I was lucky that they were good mentors themselves. They all enjoyed mentoring and so they would want to work with me, and when I didn’t know something and they noticed that, they would come over and we’d pair on whatever it is I was working on.
For a while it was hard for me to ask questions, because I didn’t want to show when I didn’t know things…They all enjoyed mentoring and so they would want to work with me, and when I didn’t know something and they noticed that, they would come over and we’d pair on whatever it is I was working on.
And then I had a few long project, like six-seven month projects, and each of them had some issues with the process that the team used, and issues coming from the product side of things. Often because product was removed from development. And so it had all of its business demands that I wanted to make, but it didn’t understand what the day to day on the tech team was like. And so, the role I took on in those projects was a little bit more project management. I was coding, but I was also helping manage the backlog, and I was also talking to the client’s product people, and how things had expectations. That was another big moment. Those two projects were big moments, because I stepped outside of my normal comfort zone of programming into a, okay I’m programming, but I’m also working with a company and I need to kind of negotiate for time.
By the end of that, I had had six months of concentrative learning, and I went in as being billed as a full developer.
N: That’s awesome. Thank you so much for joining us on Crossroads and I’ll be sure to point any questions that people may have your way. Thank you.
A: Thank you.