Made by 
Made by
September 24, 2019
Sue works in developer education / advocacy and is based in Glasgow, UK.
Aileen and Ryan Morris transitioned to coding and UX career paths in tech from non-technical backgrounds. In this talk from DevRelCon San Francisco 2019, Aileen and Ryan run through some of the friction they faced through the learning and hiring process.
Ryan: Our topic is rethinking your assumptions about your user base. A lot of what we’re going to talk about is from our personal experiences.
So you’ve heard a lot of talks today from people who like have written docs and they’ve wrote these tools and they created them. We’re on the other side of it and we’re the consumers of it and we’re the learners of it and we also come from a completely non-technical backgrounds which we’ll get into.
So really quick just to hash what we’re going to cover, we’re going to talk a little bit about our background to tell you like why we can tell you some of the things we’re going to tell you. We, like I said, are completely, we’re not tech orientated at all in the careers we’re in, the paths we’ve followed. It’s completely non-traditional.
We’re also going to talk about some of the industry patterns and the assumptions that we kind of found along the way and that were a little bit unnecessary, that kind of really increased the friction for us.
And then we’re going to talk about how we kind of challenged those assumptions and I’m actually really glad that Taylor talked before us because we have some of the same points on that and so it kind of will drive it home. Sucks she left because I was going to call her out when I was doing it.
But anyway, so really quick, if you haven’t guessed, this is me. So I’m prior US Army Infantry. For those who have no experience with military at all, that’s like the bottom of the bottom. We’re the grunts, you know. When we get out of the military, they ask us if we want to be like a janitor or fireman.
So it’s kind of not really conducive to occur to tech but when I did get out I pursued a bachelor’s degree in Business Management. A variety of things happened. I had got into several industries that were a lot more tech-related. It introduced me to programming, and then eventually my wife and I decided to make the move into tech and we decide to do that via coding bootcamps but let’s talk about that more later.
I found out about the Reach Apprentice program which is the first apprentice program at LinkedIn and we’re the first cohort. Oh, I’m not here representing LinkedIn by the way, this is my talk. But anyway, I found out about that through Operation Code. That’s where my tie is to Conrad. Yeah, they kind of pinned it up and I was like, “I’ll check it out.”
Finally, I was kept on LinkedIn after my apprentice program. I guess I did a good job and I’m now a software engineer on the My Network and Growth team.
Aileen: Hi, everybody. I am Aileen. Before we made this move to the tech industry, my background was in banking and mortgage where I spent 12 years doing customer relationship management and resolving escalated customer service issues.
And then in 2016, I completed my UX user experience designer bootcamp at GA in Santa Monica, although I initially wanted to to a coding bootcamp, which I’ll talk more about later.
My motto is always be learning whether it be getting a nano degree in digital marketing or just learning a new recipe for a donut. So that’s always been my motto.
Currently, I’m a prototype designer for a user research platform where I design visual assets for user testing so that companies can test their features and launch their products faster.
Ryan: Cool. So just really quick about our background. We’re going to share this because we kind of want to let everyone know like the conviction and like the risk that people take from non-traditional backgrounds to move to tech.
As we already said we went to these bootcamps. I attended MakerSquare which was purchased by Hack Reactor so I just talk about Hack Reactor because everyone’s like who’s MakerSquare and Aileen went to GA.
Well, the important thing about that is we struggled quite a bit to get into those bootcamps and when we finally decided to make the move, we actually sold pretty much everything we owned and we packed everything we needed in this red beastly Jeep right here, which I really miss, and we drove down to Santa Monica.
We didn’t really even have a place to live. We just like showed up and we were like, “We’re going to do this or we’re not going to do this.” So this is like a real level of risk that a lot of people take when they take this path, you know. It’s not cheap, it’s not easy.
Sometimes you leave careers where you’ve been stable for years and you’re really trying to follow your passion so we just wanted to share that because it’s really good to be mindful of, you know, these challenges so that we can reduce the frictions where we can.
Okay. So let’s get into it. So bootcamps and you. We’re going to talk a little bit about our bootcamp experience and that’ll tie into a lot of what they expose us to along the way and what the good and the bad, some of it.
So there’s a lot of text up there but essentially what that boils down to is Hack Reactor. I decided to go with Hack Reactor because of their philosophy and essentially they have a 20 to 120 not a zero to 100.
So zero to 100 is generally someone who like has nothing and they get him to proficiency but Hack Reactor had a really stringent entry-level process and where they would make you pass coding interviews and a phone screen before you can attend the program.
I actually failed it my first time, just horrible. I didn’t know anything about like scoping, you know, what is scoping, you know when you come from a non-technical background.
Also, they give you pre-bootcamp material which you have to complete and like coding. It’s basically like coding homework so we rewrite libraries like Lodash and stuff like that.
Basically, a big problem with that is they kind of have this like assumption that we know what a tree is, we know what dom is, we know what traversing all this stuff is. It’s really challenging and that’s kind of what kicked my butt the first time. I think it took me around five months before I was finally like self-study before I finally got to get to a point to pass.
Now along the way, something that’s really helped out with that is a mentor. So they actually provided a mentor. It didn’t provide, they talked to some alumni and someone was gracious enough to guide me through the quagmire that is you know all the resources. One of the good things about our industry, tons of resources but nobody knows really where to start or where to go next.
Part of that is a lot of self-study. I put two well-known ones here but it, you know, of course, there’s countless ones. I got started with Codecademy and then I moved to Udemy because a lot of Hack Reactor’s entry-level material is actually from there.
Finally, just code. I put this up here because this was one of the worst things I’ve ever been told by anybody, like whether I read it on a doc or like kind of like the Hello World like hey, just do this and you’ll be great. It’s also some of the best pieces of advice.
So yes, you need to get started and you need to build things, to get the practice but telling people why they should do something rather than, hey, just do it is very important and I think Taylor even touched on it a bit when she’s like actionable, when she’s like actionable things that we can do to actually onboard to these programs, these languages, these texts, whatever it is and that’s kind of missing a lot.
Some of them don’ts. So these are some things that were really left over. These are gaps which we had and I think almost every bootcamp had these gaps regardless of what program you go to.
One of them is is they do turn unknowns into known unknowns. However, it’s like a buckshot. It’s like you know, just grab whatever you have and just throw it against the wall and whatever sticks, sticks.
There’s a lot of stuff that you don’t really, you can’t really absorb in that period and that kind of environment and when they kind of just push out all these resources and they say, “Hey, you need to continue learning,” a big thing they used to say was “learning to struggle.”
God I used to hate hearing that, but they would just really tell you that, no, it’s just, yuck. But they’d kind of throw that out there and I don’t really feel that learning should be that way, you know. I want to be happy when I’m learning and excited but that’s how it went.
Another big thing is design principles and theory. So a lot of what people want you to know when you’re looking for the job and you’re trying to get your toe in the door, they want to know why you’re doing something, you know, and bootcamps are a lot of more like more how and they’re a lot of less why.
And so I had like, oh my God, in my first few interviews I felt like the dumbest person in the world because they would ask me “why are you doing that” and I’d be like, “My bootcamp told me to,” you know. I had no idea, I just knew I had to do this.
Or they’d be like, “Why are you doing it this way?” And I’d be like, “I read it on a doc,” you know. So there’s a huge chunk of that why is missing. I’ll pass off to Aileen so she can go into a little bit of her experience.
Aileen: Okay. So I mentioned earlier that I completed the UX designer bootcamp at GA but originally I didn’t plan to go to a coding bootcamp. A big part of that switch was because of the learning experience I had with coding specifically with JavaScript.
Learning the basics came easy for me but doing the advanced courses, it was already a struggle. And then I encountered recursion and my head was spinning. “What the hell, what is this?”
So that learning experience frustrated me and then self-doubt started to creep in and then I told myself, “Can I really do this?” And then I realized I’m smart enough to understand. So it’s not because I’m not smart enough. It’s because the documentations, the online resources that are available, beginner tutorials there would be JavaScript for beginners.
Yes, they’re for beginners but they are expecting you to understand basic foundations. I am non-technical. I came from a very non-technical background. I started as a self-learner so that was a very big struggle for me.
So in the spirit of always be learning, although I completed UX design, although I decided to do the UX course, I still wanted to do coding, so after that, I had opportunity to go to Galvanize and do a front-end web development course.
And that experience was a whole different experience because with that, I had the chance to, face to face encounter with a teacher. And the community that I was with, the self-learners that I was with at that time, were very very helpful.
And the takeaway from that is having that relationship with a mentor who is able to clarify all my frustrations and was able to like, because I was before I was just staring at my screen line by line each line of code understanding, “How is recursion happening here?” But when I got a mentor and started explaining to me really what’s happening so that’s when it clicked.
Bootcamp is over so what’s next? So this bootcamp is just the tip of the iceberg. The real work happens after that. It’s the job hunt. You now have to prove yourself that you’re worthy, you’re job-ready. And it’s another whole world of assumptions during this application phase which Ryan would talk more about.
Ryan: So I know a lot of people have probably seen or heard this phrase like “coding rockstar.” There’s another one that’s even more common than that. I bet everyone can kind of guess, you know, like, “Ninja.” you know I wanted you know, I wanted to do that so badly. Like, “We are looking for a ninja.”
Like I just read this everywhere, “We’re looking for a ninja, coding rockstar, unicorn, savant who dreams in code,” you know. Actually, I have found a LinkedIn job application that says, “Hey, who dreams in code? Do you? We want you.”
So a lot of this language is like, it’s such a turnoff. Like for a lot of people, it’s funny but when you just start reading it and you read this entry-level role that says, “Hey,” you know, “We’re looking for this entry-level ninja,” and it’s like, “But we desire five years of experience.”
You just probably lost a great candidate, you know, they’re probably not going to apply and in, like, many studies have actually shown that more men will apply to roles that they don’t meet a lot of the criteria for and women will not.
So you’re already like creating this not, I don’t want to say hostile, but you’re creating this wall, this barrier for some people. This friction that really doesn’t need to be there just from the terminology and it kind of just creates this idea of the assumptions in the people’s head. So Taylor talked about that a little bit, which is why I wanted to bring her in here but she left so, hey, can’t have everything.
So another part is the interview. Aileen had an experience about this but she wanted me to talk. Essentially a big part of the friction for this portion is when you have this format. We have this copy pasta where they’re like, “Hey, we’re looking for this person and this paper,” but in reality, they don’t need that person.
That’s really not what they want but they don’t know what they want so they just kind of crap out a document and they’re like, “This one,” and there’s like a really relevant story here.
So Aileen shared she’s a UX designer. She was interviewing for a company, did great in all the interviews got to the final interview and they sent her this long dissertation. Basically, the company works with semiconductors. And so they had sent her this paper and they were like, “Tell us what you understand of semiconductors.”
And the role was to design UI for internal tools, you know. It was like why does she need to know, like be able to tell you all this. And so she did, I mean when she trooped through it and still they’re like now we want someone who really understands it. It didn’t make any sense.
So I think one of the assumptions here is that when you can kind of hire for the role when you interview a person instead of this format, this is what you think you need, then you could probably find great candidates whereas before, you know, you were losing them.
This is just a quick slide we wanted to throw up to talk about because this was a big part of how we conquered some of these assumptions and this ties in to one of our later assumptions.
Generally, things like hackathons, meetups, open-source contributions were what really kind of closed a lot of these gaps for us. And how they did that is they got us out there coding, meeting other people who would work with us you know, help us along the way but we still encountered a lot of friction in some of these events.
For example, a hackathon, we went to a lot of AT&T ones. They did a lot of them. They would talk about like, “Hey, we have this theme and we have this sponsor. The sponsor is this tool. You have to use that tool to solve this theme.”
So when you have people who are non-technical and they’re coming in and they don’t have much background, they don’t know anything about the tool like the entire hackathon is, “What is this thing that I need to use to do this thing that I don’t know about.”
So it can create a lot of friction there. Of course, for me, one of the big solutions of this was the apprenticeship program REACH and that’s something that was not available before but is now. So I just wanted to throw it up there that this is something now that’s in the industry for people coming with non-traditional backgrounds or you know, people who are interested in tech.
There’s a lot more apprenticeships, there’s a lot more avenues to approach it than there were before. When we started there were like none. Okay.
So let’s get to wrap this up and we’ll talk about our assumptions that kind of all of that fed into.
So the first one is, avoid assuming without clearly assuming. So we have to make some assumptions, I mean we just have to, but the important thing isn’t that you’re not making any, it’s that you’re making the smart ones and that you’re notifying people that you’re making these assumptions.
A big problem is when, for example, like a quick start guide like again the Hello, World!, I’m going to use Ember here because Linkedln uses Ember. When I was going through Ember, I just Googled it. I was like, “I wonder how our docs work.” I Googled it, landed on Ember’s page. I clicked QuickStart. It immediately landed me here to this snippet.
The problem with this is Ember CLI is not really Ember, right It’s a tool kit for developing Ember applications and it’s a small thing, right, but like a lot of people that may try and approach this and maybe they’ll look at this and be like, “Oh, I’m you know, doing all this work” but in reality, the toolkit is doing a lot of that for you.
So that’s like a big disconnect for a lot of people. We actually don’t use CLI in our own team. So for example, this is how someone sets up routes and services and all that and they come to us and they’re like, “Oh, I’ll just Ember CLI,” you know, “I’ll use that,” and like, “You can’t.” So, later on, they do clarify this in the document but it’s not when you’re going to their quick start guide.
The second assumption is trying to avoid assuming that your users are just like you. And what I mean by that is people who are devs or they have experience or they’re techies.
I had one issue with an interview where basically I learned that Reacts and JavaScript ES2015 is essentially two different things because at the time, I thought they were the same thing.
I learned React with like that version of JavaScript, that syntax, all at the same time. So I had this assumption this whole time I was like, “I know React. This is what React is.” and I had an interview. They were like, “No, that’s not.”
So that was a bad place to learn these lessons. So yeah, try and avoid assuming that people have the same experience you have.
Finally, it takes a village, avoid assuming you can be an island. So Aileen touched on this point and a lot of people have throughout this entire talk. At the end of the day, it’s like people. So it’s the connection you have with people, it’s the relationships.
When you’re writing these docs, try to write with something like that in mind. When you’re making these tools, try to write with that in mind. You’re making them for people. You’re not making it for developers. You’re not making it for techies. You’re not making it for engineers. You’re making it for people.
And at the end of the day, I think that’s kind of what’s really important and that’s what really helped us out along the way isn’t really all the docs that came with it or courses, it was the people we met along the way that kind of really helped us out.
But that is really quick, our talk. Hopefully, we were able to share some of our experiences and share some tools that we did find useful on the way.
Please message us if you have any questions or if you have any feedback we’d love to hear from you guys about how this talk could be better or if it was helpful to you. So, thank you.
