Are you thinking about attending a developer training program? Jeff Casimir has trained thousands of aspiring developers and he knows what it takes to succeed at an intense training program. While a background in programming is undoubtedly helpful, you can make choices before and during the early weeks of the program that dramatically influence your outcomes. In this webinaar, we will discuss those techniques and skills and answer any questions you have!
Thursday, June 19
5:30 MDT (7:30 EST)
Can't make it this time?
Register anyways and we'll send you the recorded webinar.
Read the full transcript of this webinar:
How to Be Successful at a Coding Boot camp with Jeff Casimir & Course Report!
Tonight we’re joined by Jeff Casimir and Jeff is a total coding boot camp rockstar. You can really say that he was one of the first to enter the boot camp space. He worked with Living Social to create the Hungry Academy and then he founded G School with Galvanize. Now he’s continuing the evolution of the boot camp with the Turing School in Colorado.
Jeff has trained thousands of aspiring software developers so who better to give us advice on how to shine at a coding boot camp?
Jeff has also asked a few students, Tyler and Ed and Dan and Bree to share their experiences as well so we’re really happy to have them.
I want to remind everyone that we’re going to be doing a couple of Q&A sessions throughout the webinar so please use the Q&A app that’s on the side of your screen to send in any questions that you have; we will try to get to all of them. You can also tweet questions to @coursereport ad we will grab some questions from there as well.
So I’m going to pass it over to Jeff and let him introduce himself and tell us about Turing and about being successful at coding boot camps.
Jeff: Hi; thanks for having me and thanks people out there for listening to me talk to a computer for a little while here. Liz and I talked about what would be interesting to discuss for people who are either considering joining us at Turing or joining some other program. Like Liz has said, now we’ve done two classes of hungry Academy and G School and now Turing, we’ve had about 100 students in these intense programs in addition to over a thousand students across other programs that we’ve run,
What I thought would be most valuable would be to discuss some tips for success. I don’t believe in just throwing down platitudes like “Work really hard. Believe in what you’re doing…” That kind of stuff is a waste of time so I’m thinking about writing down some concrete tips and things people can do, and particularly ways to avoid problems – and maybe some that are surprising.
The first couple of things I want to talk about are all about before a program starts. Different programs you’ll see have created very different structures for what happens before your first day. For us, I don’t believe that much in pre-work. I like to have our students do a little bit of work at a time, where I think Dev Boot Camp is at the other extreme where students are in a 9-week pre-work thing that’s facilitated by instructors and so forth.
my feeling is you’re signing up for the program to come learn here; if you wanted to learn online, you would sign up for a different program, so I don’t really believe in pre-work that much. But there a few things that I ask people to work on ahead of time.
The first one – one of the dumbest – is typing. As Ed can tell you, in Hungry Academy one day, they were all getting fired up about something and I go see what they’re doing, and it’s some online typing race. I’m like, I can hang with this; I got this! And I believe – Ed, were you the champion? Yeah, Ed was the champion of typing.
Typing fast is useful obviously, for using computers but the thing about being a novice programmer is that you tend to make really small mistakes with a very high frequency. When it comes to programming, one dropped parenthesis, you’re in trouble. The whole file’s not going to compile; it’s not going to run, etc.
If you’re looking at the keyboard and looking at your fingers, the chance that you miss some little symbol and don’t notice it for a while are pretty high.
So one of the things I really strongly recommend is working on your typing. Even if it’s slow, as long as you don’t have to look at the keys, you’re a lot better off. In fact, if you can pick between slow and looking at the screen versus fast and looking at the keys, pick the slow and looking at the screen – because you’re going to catch those errors immediately after you make them, as opposed to trying to track them down when you go to run your code and nothing works.
We recommend a service called Typing.IO and they have a free program. They also have a paid program that gives you a little bit more guidance and support. The thing that’s really cool about Typoing.IO as opposed to a classic typing tutor, Typing.IO has you type code. You can go on there and pick, I want to type Ruby or I want to type Python, I want to type Csharp, whatever it is.
Which code you pick, it doesn’t matter. So if you’re coming to a Ruby program like ours, you’re probably going to jump into Ruby first but then typing Python, you’re using the same symbols as you use in Ruby, so you’re developing the same proficiency even if it’s not exactly what you’re going to be doing in class. All those symbols above the numbers, I think that’s where we see a lot of people struggling. People are doing fine on typing then they’re like “wait, what is e%; what is that?” so doing that stuff on Typing.IO can really improve that.
The second tip is kind of a general one about getting organized. I think something that we’re still trying to figure out how to coach well and instruct well is how to get and be organized. One of the books that’s most popular in the programming world is David Allen’s Getting Things Done. Getting things done or GTD very much prescribes a system for how to organize the things you have to do and all that.
I don’t personally subscribe to the system and I don’t think it’s necessary for students to do that either – but the ideas behind the system are really valuable and important, I think particularly for people just coming out of college or have had a job where they weren’t the boss. If someone was telling you what to do, things like your email and keeping track of tasks, somebody else really managed that stuff for you and they tell you what to do, and if you don’t listen they tell you again and so forth.
People who are accustomed to running a small business or leading teams and so forth, you’ll find that they have a lot stronger organizational skills – because they have to or they would’ve failed at that job.
Inboxes are terrible things; it drives me crazy when I look over a student’s shoulder and I see an email that I sent mixed in with their daily deals – no offense, Ed – and all these other emails that just aren’t relevant to what they’re doing. Like a lot of developers, I strive to have zero emails in the inbox, archiving things that are either done or don’t need to be dealt with. It’s not always practical to keep up with that, but I think keeping organized is really a challenge for a lot of students that think they’re organized but…
Typically in developer training programs like ours, students have two or three or four things that they’re working on at a given time and no one’s managing that for you. No one’s saying, “Remember, tonight your homework is this and tomorrow, I’m gonna check your assignment book…” You’re grownups and you need to be able to track that stuff yourself.
Related to that is attention management. I’m surprised how many students invite in attention into their workday, so running their Twitter client and IM client and messages and stuff. What typically happens, I’m sitting down next to somebody to help them with some code and I get distracted because their mom is sending messages and their sister posted a photo on Facebook and there’s stuff popping here and here and here…
In software development, focus is really critical and the cost of that context shift when something pops in, you mentally stop what you’re doing, unload the process, read the message and then decide whether you have to do something and then…probably not, and then go back and reload what you were doing before. It’s very expensive, and particularly if you start adding it up to 5, 10 times an hour; you’re losing of brain power and productivity to those distractions.
One of the small recommendations there is to investigate iPhones and android; both have privacy mode, for instance where you can schedule it during the day, 9 to noon, don’t send me notifications and don’t make sounds and all that stuff. And then at lunch, go ahead and catch up on everything that was so critical that it needed a push alert that’s never that critical.
The last piece for prep ahead of class is if you’re going to do programming, and maybe that’s reading a book, maybe that’s working on exercises; I really encourage people to strive for clarity, not for breadth. If you try out a hundred different things, you’ve provided yourself very little actual skills that you can build on in the class.
We teach Ruby and then we use Rails on top of that, and students will come in and say, “Oh, I was doing this Rails thing and da-da-da…” and I pretty much have to stop listening. Why would you do that to yourself? You don’t know how to program. In Rails, there’s a million things going on at once and there’s a zero percent chance that you’re just going to pick it up and understand what’s happening. You might learn how to type some Rails applications or make some fancy stuff happen; if that’s your goal, fine.
If you’re trying to prove to yourself like, programming is cool; I want to follow this scripted set of instructions and see something happen then that can be neat, but if you’re trying to become a developer, breadth at the initial stages is pretty much useless to you. You’re a lot better off focusing on building very small things where you can understand all or most of it.
Things like Code Academy and Code School, I really like what they’re building but those are breadth exposure; they’re not really developing skills. A textbook that I’ve used in the past is Chris Pine’s Learn to Program. It’s a little bit dated now but for someone who wants to learn Ruby, it’s a pretty good walkthrough. Some increasing difficulty Ruby challenges. There’s also the Learn X the Hard Way series, so learn Ruby the Hard Way or Learn Python the Hard Way, which also focuses on a little bit more narrow practice. It’s the hard way because it gives you very little support. It’s like, “Go build this thing” so it’s genuinely hard.
Once you actually get into the program, a few different thoughts…
The first one is sleep. In the technology world there’s a lot of romanticism around foregoing sleep and how you should be staying up all night and you should be sleeping at the office. Ed’s probably laughing because of a student we had at Hungry Academy who slept at the office for no reason, because he didn’t like walking to his apartment. So I would typically wake him up in the morning, “It’s time for warm-up.” Don’t be that person.
Somebody was saying to me the other day that when he was Dev boot camp, he made a rule for himself that he would get at least 6 hours’ sleep and I was like, yeah… that should be obvious. And I would push it even to 7 hours, at least. If you’re not getting 7 hours of sleep, it’s scientifically demonstrated that your brain can’t synthesize what you’re learning in the same way.
Whatever you’re spending that extra hour working on is not as valuable as making all your hours the next day more productive.
There was a study that if you sleep less than 6 hours for 4 nights in a row, it’s equivalent to staying up without sleep for an entire night and that it takes your body 2 weeks to recover. So if you’re not getting 7 hours’ sleep at night at least, I think you’re making a big mistake.
The second one is what I call ‘be your best self.” this was one surprised me a little bit where we saw students struggle. We joke about it now; it’s a serious issue around mental health but I’ve had students tell me things like, “at my old job, I hated it and because I hated it I was stressed out and I was on these antidepressants” or some mood-altering drug. ‘And now that I’ve quit that job, I don’t need them anymore.”
And then you get 4 weeks into class and it’s like, “Hey, how’re you doing?” and the answer is “Not good” because it’s more than just the job that led to things like having very serious prescriptions to manage yourself and your brain and your chemistry. If you’re a person that exercises regularly, I think it’s important to keep exercising. If you do other things for your care to be your best self, I think it’s really important that you do that.
In the same way of sacrificing sleep; if you sacrifice those things, you’re not going to be well-prepared to learn and you’re going to be extra stressed, you’re going to be distracted, you’re not going to be as able to focus. It seems like you’re fitting in more work time but really, you’re destroying the other work time; you’re sacrificing too much.
Once you enter the program, you need to think immediately about building a portfolio. You’ll hear people in the industry talk about how Github is your resume. There’s truth to that but it’s not really true.
One of the things we hear a lot is students are afraid of putting code on Github because it’s not good. The reality is that 99% of developers don’t put any code on Github. So if you put up some code, you’re already more interesting than a lot of other people.
There’s a certain amount of bravery in putting things up and saying, I’m not that good yet; I’m not a professional but I’m gonna put it out there anyway. That even sets you up to be able to show your growth over time.
If you’re posting your first assignments and you know they’re crap, and then later you put up things that are half decent, you can show somebody like look; I went from here to here. Give me another couple of months or a couple of weeks working with you and I’m gonna keep that trajectory going.
Having one or two projects on there when we get to the hiring stage and so forth, if I were haring a developer and I went on Github specifically and saw two projects on there, what that says to me is you only have those because you thought you should have two projects. It’s like joining model UN on your high school resume so you can get into some fancy college. You didn’t like model UN, you just did it because you want to put it on the resume. In the same way with Github, you just put up these two projects for nothing.
I would expect somebody who thinks they’re a decent developer to have 8, 10, 12 projects up by the time they’re applying for jobs, and that those projects should show some kind of ongoing commitment, not just like, “I made a thing; I posted it. I made another thing; I posted it to a different project. But here’s a project I started; here’s an initial commit…” then I worked on it more and posted more commits and more commits. Even if it was only in the course of a couple of days or a week or something like that, show that you build projects and that you care about them and you know how they evolve.
Related to that, Jerry Seinfeld in talking about becoming a good comedian, he says that most comedians spend ten years building up their first hour of standup material. And the question after that is how do you build good material? And the answer is, I write jokes every day.
I think particularly when you’re learning, it’s important to write code, commit code and post code every day. So I have a goal for our students that their graph is almost entirely green on Github; that they’re posting code publicly every day. Even if it’s a small exercise, even if it’s a trivial thing off a project like find the first ten prime numbers or whatever it is. Posting code regularly or ideally every day – maybe every weekday if you want to take your weekends off, I think is extremely healthy and demonstrates a real commitment to your craft.
The third piece is – the phrase I use is “no permission to open source.” There’s a perception that getting into open source is very difficult. The problem is that new developers have completely unrealistic expectations about the kinds of projects that they can contribute to.
When you look at Ruby as a language, Python as a language, Rails, Jango, etc… These are huge open source projects where thousands of people have contributed; hundreds of thousands of people or millions of people use them and the chance of you having the expertise to write code, to post it and get it accepted is relatively small.
If you want for a kind of vanity commit, you can usually edit or add some documentation and get that included. It’s pretty cool to have a commit accepted to Ruby or to Rails or whatever. But it’s much more practical if you want to do actual programming and you want to do traditional open source, you need to find a small project; a project that has 2, 3, working on it and hundreds of people using it. The chance that you can actually help there is pretty high.
I have projects myself that I don’t really have the time to maintain them and if somebody were to come along and say, “Hey, I took care of this issue; it’s a little bug..” things that are just sitting in Github waiting to be solved, I would hugely appreciate that, and there are a lot of other developers that feel the same.
But that’s only one model of open source. You don’t need anyone’s permission to contribute to open source. To contribute to those projects, yes, you do. But if you’re doing things, like I mentioned projects and excesses; if you’re solving those exercises, post the solutions. Create a repository and post solutions on a daily basis.
Does anyone else care about that open source? It doesn’t matter. Maybe some student is going to come along and they’re searching for a solution to a certain problem and they can find my solution and reference it. But maybe it’s just mine and just shows what I’m up to. That’s what I mean by you don’t need anybody’s permission.
Just post what you’re working on. Nobody’s going to come along and ridicule you or judge you for how crappy it is because the people that would do that, the kinds of attitudes that would lead to that behavior; they’re too chicken to post their own stuff. So just be bold, be brave, put your things out there.
That’s my pause point for some questions.
Liz: Wonderful! Thank you, Jeff. We’ve got a few questions; Jeff, what do you think about live-in boot camps? Do you think that’s helpful to have a house where everyone lives and learns at the same time or do think that’s harmful?
Jeff: Yeah; Several times I’ve had people be like, “You should make a reality show!” It just sounds terrible and we don’t more reality shows. Living in the same house…I don’t know; I couldn’t do it. I need a little bit of space from people.
It also seems even more like you’re inviting an even smaller pool of the population; people that are happy to leave their families or significant others or kids or pets and all that. I personally wouldn’t want to do it. I could see some of the appeal…
With our program, we have definitely seen people who come from out of town, that has some advantage, that there aren’t the distractions of those pets and those significant others and the kids and the friends pulling you away. That’s pretty consistent, particularly as the program goes on.
Like, in the early weeks and months, your friends and family, they all understand you’re doing something serious. But then after 3, 4 months we see people get pulled away into more things because the outside world doesn’t really understand the level of commitment that you’re trying to put in.
There’s always debate about which language should you learn and the answer is, if you’re going to actually learn a language, it doesn’t matter too much which one it is. Because if you truly learn it and you understand what’s happening, you understand the design patterns that go into it, you can convert that knowledge really quickly.
It’s not like they can show up day one and start writing IOS apps and Objective c but if you understand how to program in Ruby, you can pick up Objective C in a couple of weeks and get functional with it.
Liz: We’ve got a question from Mike and then let’s introduce all the other lovely people who are here with us. He says, I can write code via eBooks and video tutorials but I can’t get to the point where I can write my own code. How can I climb over that huge wall?
Jeff: It’s even more than a wall. I think it’s like crossing the chasm for learning, where there’s a huge divide between following tutorials and writing things on your own.
I think part of the problem is the expectations. You can’t write and sell a book that shows people how to build tiny little exercises, you have to write a book and say, “here; build a blog engine in 400 pages!” and it’s great. Then you get done with that and “Now I’ll build Yelp!” The problem is, you’re not at all prepared to build something as complicated as Yelp.
But your expectations have been set to that level because you just typed this huge blog engine and it worked and that was cool. Now I want to build something else amazing and big.
I think the solution – it’s kind of a non-solution is to just try smaller problems. If you want to build big things, you have to work up to it. For us, we publish all of our curriculum open course. You can check out tutorials at Jumpstart lab.com and you can find all our projects in there.
A project our students just finished today was to build – Liz, did you ever play the game Mastermind when you were a kid? You set a secret code and you have to guess how many yellows, how many greens, how many whites, how many blues…
Jeff: So we built that in Ruby. For me, if I had to build it, it would take like 4 hours. For our new developers, they worked pretty dang hard for like 4 days and they just barely got it done.
Something like that is an approachable problem that you can actually succeed on, especially if you’re unable to commit nights and weekends to it.
Liz: For sure. and your students right now have been there 4 days, right? They started on Monday...
Jeff: No, they’ve been here 3 weeks.
Liz: Oh, I’m sorry… so now I’m going to unmute all these other lovely people. So Ed and Dan and Ty and Bree, if you all want to introduce yourselves. Tell us what you are up to these days.
Bree: Sure, I’ll start. Hi, I’m Bree. After graduating from Jeff’s school, I started working with a product company in the healthcare industry called iTriage. Currently right now, I work with a group of about 0 developers but we’re divided into smaller teams of about anywhere between 6 to 10 people. My team has about 8.
Right now we’re working on re-architecting and rebuilding a pretty major database and then we’ll build out an API for that. It’s been really good so far.
Liz: Awesome. Dan, do you want to introduce yourself?
Dan: Sure; I graduated the first class of G School last July and after that,
Liz: Ed, you want to introduce yourself?
Ed: Sure; my name is Ed Weng. Prior to enrolling in the Hungry Academy which was the original Turing School—
Jeff: The alpha version, basically.
Ed: The alpha version – I was Jeff’s guinea pig. I worked in investment banking up in Wall Street and now I am a fulltime developer at Living Social working on their mobile platform.
Liz: Amazing; okay, Tyler?
Liz: Very cool. Jeff, do you want to read a few questions for all the graduates?
Jeff: I’ll start with Ed since you finished the longest ago now and you’ve been working for about 2 years. What things do you feel like we missed in Hungry Academy?
For those that don’t know, Hungry academy was our first long-term program; it was 5 months from… I know you graduated in July. It must’ve been March to July of 2012. Were there things that you hit in your job that were like, I’ve never seen this before, I have no idea what’s going on?
Ed: No, not really; I was—
Jeff: Aw, that’s too soft, Ed!
Ed: I was pretty surprised with how prepared I actually was once I finished the school. I felt like I could actually contribute to the team.
I think one of the things that you really miss if you want me to nit-pick, is you don’t really learn how to work on large teams. Most of the projects that I was involved with were 4 or 5-person teams. At Living Social, our organization is 150 people and with that size come some organizational challenges. So that’s definitely something that you end up picking up on the job.
Jeff: Tyler, with rent Path, you work from your kitchen or your couch. Does that mean that you’re by yourself all the time or are you still tightly integrated with a team?
Tyler: Super tightly integrated; we use a virtual office and we have to actually work in these things called “pods”. There’s two senior developers and two juniors in our pod and I pair program every day. Not necessarily 100%. Sometimes I’ll be working with the senior dev but he’s also like a tech lead so he’s got to step out for meetings or whatever, so I’ll just grab a story off pivotal and work on it. I definitely like I can do that.
Jeff: We get some push-back from people, “well I could just read a book or I could just do this online thing and learn all the same skills” but so much of what we teach is about how to be a part of a software team, not just a software developer.
That’s one of the parts that really shine to the students when they get out. They’ve worked through a lot of different projects in teams and they’ve fought with team members and they’ve worked with people who though they were awesome and it turned out they were not that great, they’ve worked with people that they thought weren’t great and it turned out that they were awesome.
Bree, you have run a lot of teams in the past and worked on a lot of teams in different contexts. Was being a developer on a software team similar to marketing teams and things like that?
Bree: I think the biggest difference if we’re going to use the marketing context, when you work on other teams and other contexts, you may in fact spend a lot of time in meetings trying to make decisions. I think the real big shift is when you have to sit next to someone in front of a screen and actually build something; build something concrete, see how it works and bat ideas around about “I don’t know what that error means. Let’s go figure it out, let’s research it together.”
So I think it’s a lot more in-depth. In other contexts and other environments, a lot of your working with people is about delegating; I’m gonna do this piece, you’re gonna do that piece. I would say with programming, certainly pair programming it’s “we’re in this together all the way through” so it’s a lot closer-knit.
Jeff: It reminds me of some teams will use phrases; there are a couple of different variants. One of them is “code talks”. Instead of debate, debate, debate, what would be better this, would people like this? I’m sure Ed knows this where at Living Social they do a ton of ab testing – it’s instead of having days and days of meetings about a feature, let’s just build it and try it out with some people and see what happens. It’s kind of a nice, practical focus of a lot of teams.
Liz, did you have any more questions come in or shall I keep hammering them with questions?
Liz: I think there are a lot of staggered start dates now with some of the boot camps. Do you think that it’s better to start a boot camp as soon as possible if there’s an option or do you think like, give yourself more time? When you got into G School or Hungry Academy, did you wish you could start immediately or did you want to take time before that?
Jeff: No opinions…
Liz: Either way…
Jeff: I think for us on the organizing side, we’re really excited about the potential of what’s going to happen when we have multiple classes in session at different points of progress, what that means for student mentoring; students interacting with each other.
One of my frustrations maybe with things like G School in the past is if we were just running one class at a time, people who were on the fringe; we couldn’t spend a lot of time addressing their needs.
Tyler for instance, got into data structures and algorithms. If you have 2 or 3 people who are into data structures, all you can basically afford to do is like, “Go try this thing; go read this book…”
But is you have 2 or 3 people per class and you have 4 classes going at once, now you got 10, 12, 15 people who are interested in this slightly more niche topic and you can devote more time to them and more instructional resources to them. So I’m really excited about what that means for us.
The other part that’s interesting on timing is somewhat of a surprise to me but it makes sense in retrospect – is that a lot of students used to take time off after the program. Even for us, people are in class for 7 months now; most of them have burned up all their savings that they have and it’s hard to go that long without a paycheck. But people still try to take off another 2 or 3 weeks because we work tem pretty damn hard.
Often, people go into their jobs and we get feedback like, “I’m not very busy’ or “My job is easier than class was.” and that’s how we want it. You should practice harder than you play. It’s better than getting into a job and being like, “Oh my god, it’s impossible!”
Ed: One thing I would say just about the original question is that when I first started learning how to code, I tried to do it on my own, and what I found was that it was incredibly difficult. I would try and look at code samples and not fully understand them, I would try and run through tutorials but not absorb so much information.
I think what Jeff was saying, there’s strength in numbers. So I think when you’re surrounded in an environment where everybody is trying to learn as much programming as possible, some pretty amazing stuff happens. Things just click better. I think you learn things faster, you pick up concepts faster. I think you’d be surprised at how much more efficient it is to learn in a classroom environment than it is just trying to study on your own during weekends or nights.
Jeff: You reminded me also of another thing that we’re trying with Turing. This is like our third version so it’s a change of rules again. Basically, anybody can apply at any time for any class in the future. We don’t really have deadlines.
Like right now, people are applying for the July class and people are applying for the September class. People apply; we evaluate them and we interview them and if you’re a fit then you’re a fit whenever is good for you.
right now, we have people signing up for the September class or to an October class and people are going to start signing up for the January and February 2015 classes just because that’s what works for their schedule.
That has some downsides to us because people get really motivated by deadlines, right? If you make a deadline, you’re going to get a spike of applications right at the end of the deadline. But practically speaking, I don’t just want to make up some arbitrary date because we can. If you’re a fit, you’re a fit. If you want to come in October or January why should it matter to us?
So I really encourage people and obviously, I’m biased because it helps me, but if it’s something that you want to do, just apply and get in and then worry about when are you going to do it? When are you going to start? Can you afford it? All those things.
Bree: Along the lines of what Ed was saying, I think also important in having the group around you which is very helpful; it’s also dedicating yourself to a truly immersive experience.
I think back to my college classes; I had a class on a Monday and a Wednesday and that’s when we met every week. For me personally, that would’ve been impossible with learning to code. Having the majority of your day, all day every day for a pretty long chunk of time made a huge difference for me because prior to that, I was trying to learn on my own and even learn with some help maybe once or twice a week. And not being focused on code every single day for really long blocks, it was too hard to get up to speed quickly and retain that knowledge.
So I think like learning a language, the best way would be to be around people who speak the language all the time and do it consistently.
Liz: Definitely. We’ve got a question from Greg who says: Can you get into programming in your forties? And I know that all the faces up here young, so… I hear programming is a meritocracy but also that there’s some age discrimination. Would anyone hire a junior dev in their forties?
Jeff: Yes to all those things. Is there age bias and discrimination in programming? 100% yes, there is. Is it prohibitive? No…Ed, is Conan your team lead now?
Ed: He is not my team lead but he is the lead of a team.
Jeff: We had a student in Hungry Academy who was 40, 41; we have a student now who’s 42 or 43. It can definitely happen in your forties but I think there are some extra challenges when people go into the interview process. There are some prejudices, I think particularly for men in their forties; like, are you gonna be difficult to work with? Are you gonna have a problem where your team lead is 10, 13, 20 years younger than you? Are you gonna be able to work in that kind of environment?
I think those are legitimate questions just as there are legitimate questions for a 25-year old who comes in thinking he’s hot shit, right?
But it can definitely happen and I know that our friends at Dev boot camp have been talking lately about how many older students they have. Are there issues? Yes. Are there people that have a bias against older junior developers? Yes. Can it be done? Yes.
Bree: As one who is 38 and had a completely different solid, lucrative career for over 10 years, it was a big decision and I worried about that a lot. One of my classmates from school, I also work with him at iTriage and he’s 3, 4 years older than me.
I think one of the interesting things about being in that age group and deciding to go this path is there are a lot of other things that you bring to the table. You have a lot of past experiences that can be really applicable in what you’re doing in programming. So whether that is creativity or working with a team, thinking about business rules and consumer needs differently; whatever your past experience is, you can absolutely bring that to the table. I think that’s an asset and the programming comes quickly once you’re open to learning.
Jeff: It reminds me of my brother-in law who does Iron Man triathlons. In the Iron Man, the most successful triathletes are in their early, mid and even late thirties. Even though the body has started to deteriorate to some extent, your grit is so much higher at that age that you’re able to muscle through. And that’s kind of how I think about it with students who aren’t in their twenties, who ate in their thirties or forties, is like you know how to deal with hard situations and you’re not going to be like, “Oh, you gave me negative feedback, boo-hoo-hoo!”
You’ve worked with challenging people, you’ve done hard things; I don’t have to keep on top of you to stay organized. You’re a true grownup and to me, that’s incredibly valuable.
Liz: We have an interesting question: What does the nonprofit status of Turing accomplish compared to other types of boot camps?
Jeff: Tremendous headaches for me – that’s the primary thing that it does so far. I’ve been in education now my whole, adult career starting with Teach for America and going through teaching public school, Jumpstart Lab and all that. We’re in it for education.
Over the past couple of years, as you know we did hungry Academy and G School and now Turing, there are a lot of people who are just not so sure about their motivations. You can do back-of the-envelope calculations and say, all right, if we can charge 15 K for class and we get 20 people to come and we run it for 10 weeks and we run 4 of those a year, you’re talking about some serious money.
I don’t care about that and I wanted to make it clear to people that that’s not our thing. If we were making money, we would lower tuition. So we’re going to just get by. We’re going to take in the minimum tuition we need to keep things rolling.
We’re in a basement and we have shelves from IKEA and not from Knoll and not from Herman Miller because that’s a waste of money. Why would I take money from somebody who I’m telling to now be unemployed and then turn around and waste their money or pay it out to investors and all that stuff?
There are consequences for us. A lot of our business processes are a lot harder for being a nonprofit. We have higher reporting standards and all that. I hope that as we demonstrate our success with Turing, that one day somebody like Google.org will say to us, ‘Hey, we love what you’re doing. You should find more people of color who want to be developers and here’s a million dollars to pay for their tuition.” That kind of stuff becomes more possible with the nonprofit. So in the long run, my fingers crossed, it will mean a lot for our students. For us as an organization, it means only negative…. like, more work, more challenge.
G School, our former program, they just announced a big investment today of $18 million and I’ve been thinking about it a lot all day. Answering to investors is orthogonal to the needs of your students, like, do they go opposite directions? If we had investors or we wanted to attract investors…
Investors only put in money because they want it out, right? And technology investors, they want 10 X returns. If you have an education program how are you going to deliver a 10 X return? you’ve got to drive down costs which means hiring more and more junior instructors or people that don’t really know what they’re doing, packing your classrooms with more people and/or raise prices; raise revenue, right?
Both those things are detrimental to the educational experience. Not only are those not acceptable to me but I just want to take them off the table. As a nonprofit, you can’t have investor so - done. We never have to think about it, we don’t have to talk about it.
Liz: That’s awesome. Jeff, you’ve given us some good tips on before the class and during the class. Do you want to give is some tips on once you’re finished with the boot camp?
Jeff: The hiring piece is really interesting. It’s one of the parts I enjoy most. I think of it as this human Sudoku puzzle of figuring out students, trying to figure out what kind of team is this person going to work on best, what kind of environment are they going to most succeed in and trying to help them find that fit.
I wish we could get students jobs, like deliver them on a buffet and like, here are all the jobs, just pick the ones you want! That’s not the case. Our typical students apply for 4 to 8 jobs, the interview from 3 to 6 of those and they’re offered 3 to 5 of them… maybe 2 to 5 of them.
One of the things that surprises students is how different it is company to company, where some companies will go through the whole thing from “We just got your resume” to offer in 4 days. In other companies it can be 6 – 8 weeks and interviews that drag on and on and on and on – and then you end up at a no. I waited to go for 6 interviews and I was out there for 3 days just to get to no… So I think start early is something to really think about.
But then another piece is building your network. For us, I’m privileged to have a good network in the Ruby community and I also leverage that for our students. But it’s also important for students to start their own network and you need to get out to meet-ups and participate in the community whenever you can.
Programing’s an incredibly small world and just about every place our students want to apply, they’ll say, “Oh, I want to go to this company and I don’t know anybody there; I never heard of it.” When you pull out an about page or look them up on Github or whatever and it’s like, oh yeah, there’s this lady I met at a meet-up one time back in DC; let me shoot her an email. Those connections are tremendously valuable to getting interviews.
Students can do that on their own so you don’t need me. You can start attending the meet-ups in your area. If there aren’t meet-ups in your area, there’s a Ruby hangout which is a Google-based meet-up that happens once a month. Just starting to connect with people outside your program before you need them.
The last piece on that comes from the investment world even though I was just bagging on investors. One of my friends posted a great tweet which is: If you want money, ask for advice. If you want advice, ask for money. I think if you go around asking for jobs, you’re not going to find a lot but if you start talking to people about “Hey, I’m looking for a mentor who can help me one hour we week for some pairing at a meet-up.” Overall just trying to meet with people and get coffee and get advice on “I’m moving to this town” or “I just moved to Chicago and I don’t know anything about Chicago. Can I pick your brain about Chicago and what companies I should look at?”
The chances that those people are either going to want to get you involved with their company or even more likely, they want to introduce you to somebody because they get to win on both sides. You kind of like them and owe them a favor because if they help you find a job and the friend that they introduce you to, they get a plus-1 from them for finding a good person for that company; it’s like a win all around.
If you’re sending your resume to email@example.com, you might as well throw it out the window because it’s not going anywhere.
Liz: just for all the other panelists, and I know you all have different experiences but once the program was over, what do you guys think was the most integral part of actually landing that first job? Was it something during the program; was it something you did after the program? What are your tips?
Ed: One of the bigger things for me was knowing what I wanted and what I was looking for in a team but not being too picky. I think coming out of this role, you have to understand that you are still very new to the programming career and you are still a very junior programmer, and as such you need to really seize and capitalize on good opportunities and learn from them and then maybe in your next job you can be a little more picker and a little more picker until you find that perfect job that you really want.
Liz: I think that’s good advice. Anyone else want to share their secret?
Tyler: I’d say persistence. You just have to not get discouraged, I guess. And like Jeff said, companies are very different on how they do the process. But I guess also, you have to know how to do a technical interview. Like every single interview, that’s what it was. So just be prepared for that, I guess. It needs more communication, I guess. It’s not like “Oh, can you build x?” It’s like how do you think about the problem and how do you attack it?
Jeff: There’s a lot of voodoo around technical interviews and I think of it as standardized testing from my K-12 background. If you know math and you take a standardized math test, you’re going to do really well. The best way to pass a technical interview is be good at programming.
Now, there’s some practice to it and you might do a bit of purposeful study around technical interviews but if you can code and you can work with people and sort out complex problems, you’ll do well on the technical interviews.
Liz: Awesome. Wonderful… thank you guys. Thanks so much for joining us and for joining the Turing School for the webinar and thanks so much to Jeff and Bree and Dan and Ed and Tyler; we can’t thank you enough for being here. If the audience have and additional questions for Turing or for Jeff, I will sent out contact info in an email after this.
Also, if you’re considering applying to Turing School, we have and exclusive scholarship for you. Email firstname.lastname@example.org and if you’re accepted to Turing, you’ll $500 off the tuition, which is huge!
If you have any questions about Course Report, please don’t hesitate to reach out to me. We’ll send out the recording of this webinar afterwards so check your inboxes for that. Please visit Coursereport.com and sign up for our email list and you’ll get all out future webinars and interviews in your inbox each week.
I appreciate everyone being here and we will see you at the next one.