Peter DePaulo, Front–End Developer + Viking Alumnus: From Bootcamp to Job

Peter DePaulo, Front–End Developer + Viking Alumnus: From Bootcamp to Job

Connecting the dots between bootcamp to first job, and why doing what you love counts.

Peter DePaulo is an esteemed alumnus of (and early infrastructure contributor to) Viking Code School. He’s now a Front–End Developer with Mind Body Online.

Prior to becoming a software developer, he worked as a writer and within the biochemistry, environmental engineering, architectural design and startup realms.

In this Codecast, Peter talks about knowing what you want as a developer, why tough hiring practices are great signs of solid company culture and stoking confidence in your capabilities.

Key Theme » Readiness Brings Depth

“It’s a field of infinitely deep specialties, that’s what I’ve learned being in the industry. What you’re learning is this stack of technology to solve business problems...If you can do the job – which I believe that you’re well-equipped to do at the end of Viking Code School (any quality bootcamp experience) for web application development – then your goal is to represent that as well as you can for transitioning into a legit job." – Peter DePaulo

The Codecast

Watch on YouTube

Quotes

"I talked to an HR person, then a recruiter and I asked both of them if I could contact the person I would be working with and they said "yes" and they gave me the email before I was supposed to get it. As long as you can get on that call – the obvious step is be humble about it and just ask."

"Legacy code, dear lord that is something I do not wish on my worst enemy is some of the legacy code that I’ve had to deal with."

"I have interviewed several people now. 'Do you have any questions?', we ask them, we leave 20 minutes at the end of an hour long interview – do you have any questions and a lot of it starts with awkward silence or their questions are very topical."

"...so the hardest part was getting up to speed with how everyone interacts, the lingo that they use to describe things, the software, the massive code base, fixing bugs in code someone wrote four years ago that is no longer there, and I can’t even ask them about."

"If you’re doing something that is making you sad, stop doing it."

Full Episode » Transcribed

Erik

Hello, and welcome to the Viking Codecast. With us here today we have Peter DePaulo, the one and only. A former graduate of the Viking program from years long past, Peter is a developer right now with Mind Body Online – a public company down in San Luis Obispo, CA. He’s done all sorts of things from design to academia, to side projects to mock programming, to Meteor explorations to JavaScript on top of a C# stack. We have many questions for how the heck you stitched that resume together, and maybe you do, too! But definitely excited to have you back here Peter, so welcome aboard and we’re happy to hear what you have to say.

Peter

Alright, well first of all I’ll just do kind of the classic little introduction. My name is Peter DePaulo; I love JavaScript (laughs) which is not a popular stance a lot of the time. First of all just some context, what I do day-to-day I’m a front-end engineer so it’s sort of my job to love JavaScript because if I don’t then the people surrounding me will just talk shit about it. Oh - can I cuss on this, sorry?

Erik

(Laughs) Just do what you’ve got to do. We’ll put out the rating that it’s PG13.

Peter

Okay. So they will talk it down quite a lot and I basically have to make a case for it every day. That being said it is getting a lot better, so that’s what I do. What the stack I work in is TypeScript, actually. We’re already one step away from raw JavaScript. Half of the stuff we work in is JavaScript and half is TypeScript. I had to actually ask, because we’re a public company like what I could share and what I can’t and I thought they were just going to say, go ahead it’s a technical talk you can talk about whatever you want. And they were like “oh, you can’t talk about this, this, this and this, you have to say it this way, you can’t say this.”

So I’m going to be a little bit vague about parts of it which is frustrating because I’m working on something really, really cool that I cannot share because it’s “material nonpublic information.” I was explicitly told not to tell you guys about. But, what I can tell you is it’s a C# stack, so back in C#, it’s all Microsoft so that just means Microsoft’s favor of SQL, C#, some ASP in there which is really rough if you have to work in that. Then going up to what you would expect from a front-end which is the same everywhere.

I spend a lot of time doing a lot a variety of things; it’s more than I thought it was going to be as a front-end engineer. I thought it was going to be a lot of implementing designs and just a lot of basic JavaScript but the front-end has gotten really fat and so we actually end up needing to do a lot of data manipulation on the front-end. That’s just not for display purposes which sort of surprised me, and then occasionally I’ll have to dip into C# but very rarely and it’s only topical, I’m not writing any of the logic in C#.

That being said, how did I get here? The very short version is I studied biochemistry and a bit of urban design in college, really eclectic. I went to UCSD, as I was leaving I became a freelance writer. So I was leaving college and I had no idea what I wanted to do, I thought I was going to be a lawyer, a doctor, an architect. I actually thought that for a second. I pursued each of these like really intensely, it was just thoughts actually. I worked for the San Diego Architectural Foundation, I worked at a hospital. I came this close to shadowing a Patent attorney and then I would realize — most quickly out of all of them – the lawyer was the one that dropped off the quickest.

Then at the end of all that I was like: “OK, I’m going to be a writer.” I got a job as a remote freelance writer and I wanted to write about environmental issues. I’m a closet environmentalist – that’s what my friend calls me because I have never made it my full thing – but it’s probably one of the most important things to me, so all of my side projects end up touching that.

Erik

I think you’re "out" now; you’re out of the environmental closet.

Peter

Yeah, this is live, right? I’m an environmentalist! So I had a ticket to Taiwan at the end of my last year of college, a university in Taiwan, south Taiwan I was going to be writing basically about environmental science in Taiwan. That was my plan and my friend says, hey — I’ve got this idea for an app. And I had very little program experience, it was all like root of memory, HTML, CSS, I thought I knew some Java Script but it was like barely anything and I did not have any mobile experience whatsoever.

I thought the idea was really cool, we ended up building a bunch of crap. It was called Campulus, it was a really terrible messaging board for college students to be able to post events, then we found a company that was doing the exact same thing and they had just gotten a seed round of almost two million dollars – that was CampusQuad. We contacted them, they said how did you get – you don’t have anything how did you get people on this? You guys must have something going on, and then my friend flew and I drove to Silicon Valley, San Carlos and then they hired us pretty much. They didn’t purchase any of our assets or anything they just wanted whatever we were doing on their platform.

I did marketing and design for them, and it was extremely frustrating because marketing at a startup if you don’t have product market fit just means going and trying to find product market fit. I was really just going to people and like begging them to download the application, try it, watching them use it and then getting feedback so we could change the application which would have been great if we were actually lean.

The developers had kind of a different process and so, when we would put bugs or things that would be bottlenecks in the user flow in the board, the developers would have stronger arguments in their minds for why they needed to focus on other things first. So we felt the user pains really, really strongly on the ground, they felt the technical pains at a high level that they were trying to solve. So real problems on both sides just different, I realized I needed, if I was going to be in technology to actually learn at least what it was all about. I’m embarrassed to say this, but our staff was layerable PHP and someone said, “why don’t you use Ruby on Rails?” It was a Stanford student, our first client was Stanford!

Side note, we went through the Stanford Startup Accelerator, that was a really cool experience, probably wouldn’t have gotten to do if it wasn’t for that startup so it was a great experience. But, side note: I was super embarrassed to say when someone asked: "do you know Ruby on Rails? Why are you guys not using Ruby on Rails?” I thought it was "Rubion" Rails, and I said that talking to people. I never wrote it out thankfully, in like an email, that would have been so embarrassing. Then I was like: “what am I talking about?” I started Googling it and I couldn’t find any results for "Rubion", so I was like: "what is Rubion?"

Fast forward a little bit, I left that company for some personal reasons and because I really wanted to just deep dive into this whole learning to program thing. Fast forward again: I ended up getting hooked up with Viking Code School and went through it. It’s a very different version than it is now, and that was I think, a couple years ago. I guess I have to fill in the gap between Viking Code School and a job at Mind Body.

That very short version is: I started another company called Omari, which was super fun, crazy rollercoaster. We actually did get clients – we had a cool product. We had a really cool business model; people were really excited about it. It was basically going super well and then it crashed. That was my biggest – “burn my fingers” – I think it was one of my biggest personal failures I’ve experienced. Everything else was pretty good before that and this was just like really, really good and then off the cliff and down.

Erik

Can you talk about that a little bit more, what you guys were doing, how it came together – your crazy, crazy days of driving around? (Laughter)

Peter

I think the last Viking Code School related video chat I was on – I was calling from a car on the way to pitch a client which was pretty big. It was software for individual businesses that we were making. Each client was pretty substantial, and we had a really crazy culture at Omari. I am still friends with everyone there, all a lot of young people, amazing talent, but very raw. I think one of my cofounders was yelling expletives when I was video chatting with Viking Code school...so I’m surprised I’m invited back.

(Laughter)

What we were building: we were working on two things. One was a talent investment platform. So on our side internally we’re building this tool basically saying: “if you guys want to work on something you’re investing your talent into this company, and we don’t want to just build these un-maintainable products. We want to build things...like, we have some reason to build things that are maintainable.” That was creating a market incentive for maintainability of freelance projects. The problem being solved is having done freelance in three varying capacities: which is writing, design and programming. I realize that quality goes down because it’s so easy to just say: “OK, I’ve got a deadline here’s a shortcut, I’m going to take it.” And you end up with inline styles and just crazy method names, stuff like that.

I was working with some people and they were like: “oh yeah, this is a really cool idea, why don’t we do this talent and investment platform, and we use this new technology called Meteor?” So we were using Meteor. The other thing was basically our first niche to test this business model out was an e-commerce site, e-commerce businesses. Anybody who was a small business and wanted to sell online, and we built a rollout platform on Meteor. It was really cool, really technically advanced for some of the stuff we did and it was all JavaScript.

I’m pretty deep in the JavaScript game now for a while. It got great responses; we worked on some really fun projects. One was a fried chicken delivery service – late night fried chicken and waffles delivery service – called Kickin’ Chicken. One we worked with was selling prints. We ended up not finishing his project because he dropped out, he was a strange guy, but he was selling printed calendars and things like that. People were buying them from him; he would get pictures of people who had kids and make calendars for them.

I was like: “why do you have a business, there are so many people, so many online services for this?” Anyway, it ended up not working out. One other guy was a producer, musician, so you get this idea, a wide variety of clients in this one product that was meteor. The internal communication platform and disbursement, so there were pie charts that would – given someone’s effort when they worked on a project – they would have some stake in the project. We would get paid over time instead of just in a lump sum based, on the ability to increase their business, which is at the end of the day – what you care about.

Programming is business needs – it’s just all information, you’re adjusting business needs.

That was Omari, we had several clients and it ended up not working out because of a meeting where misinformation was passed. All of the clients were in this niche group of people in Santa Cruz and they all started talking to each other. We probably could have pulled it out of the wreckage but it was a pretty demoralizing blow for everyone to have all of these paying clients and then no paying clients.Five people paying us on Monday and then zero dollars coming in on Monday, after we worked so hard for three months on it.

Erik

From a technical perspective you were still relatively fresh with JavaScript and you were diving into things with Meteor, and working with clients. How did that all come together?

An "engineering mindset" requires real discipline.

Peter

That’s something that I’ve learned more about now is – just sort of what you don’t know and what you do know. I think my strength has always been learning whatever I absolutely need to do – to get something done. Now, I have become more of like an engineer in that I actually know why and what I’m doing. That was definitely a harder thing for me to learn, it’s like the discipline side, versus purely driven by caffeine and passion.

I didn’t know as much as I should have for what I was doing, but I got really lucky in that the people involved that were really excited had some very deep technical knowledge. They were the type – a couple of guys were the type that had been just programming their whole life. Young guys, but they were just really talented, and so we had a good trade of knowledge. it ended up being – I hate to use the word “synergy,” but it had good synergy for our talents.

I ended up being more of like a manager, like a project manager which means you’re serving the people who are working on things so they can get them done. I wrote a lot of the JavaScript myself as well, because there were only three or four people at the start.The deep data side were these guys that were way more technical than me. Then the interfaces – I wrote a state machine for a store that wanted basically – it had weird hours and it wanted to have either a switch that would turn them on or off. But, the switch would actually turn it on so the store would be on some hours and off other hours. So they set the hours, then they had an on or off switch for whether the store was on, whether it was off or it was on during these hours that they set. Like a real business. It’s kind of complicated.

Erik

(Laughs)They were aware the internet doesn’t turn off at night, right?

Peter

The cool thing about it basically, what it meant was: they had two separate user flows and then this little logic thing would say: “do I display at this page, which flow am in, what do I display?” Which is really easy to do in Meteor. It was really fun to work on. That’s something I was pretty proud of. Getting that to work – because it was a weird requirement, weird technical challenge. You had to perpetuate the data, it was pretty complicated and that was really fun to work on.

That was Omari...got my fingers burnt and I started freelancing again. But this time doing programming and I realized what I really wanted to spend my time doing was actually writing code. Not like managing clients and managing myself and managing projects, and billing people and filing the taxes for that – all this other stuff that comes with freelancing, it’s really a big headache.

I just wanted to write code. So I applied for a few jobs, I wanted to stay for at least one more year in San Luis Obispo. It’s close to my parents and they were going to be moving so I was going to be managing their house. Personal stuff aside – I wanted to stay in San Luis Obispo and really the only serious player in technology in the area is Mind Body – and they were going through an IPO right as I was applying.

Interviews: be prepared.

I applied and it was this really crazy application process where everything was in flux in the company. They didn’t know what they could share with me what they couldn’t, because no one really knew what IPO meant for them. My recruiter mixed up the hours so I did really well on the homework and during the interview he was like: “where are you?” I was like: “I’ll be there in an hour and they’re like no, it starts now!” So I rushed over there, it’s 20 minutes away from where I’m living right now, or 15 minutes away from where I’m living.

I came in and the entire team that was interviewing me was sitting in a row behind a chair and a desk and I was told explicitly it would be a non-technical interview because I already did the technical interview on the phone and then I did homework. It was just a keyboard and a screen and four people sitting behind me at a 90-degree room waiting there for ten minutes. I was like: “oh jeez, I am not prepared for this all.” I hadn’t practiced that morning. I thought I was just going to have this cushy talk to people / feel-good interview that was for cultural fit. It was not a super difficult technical interview but it was just the stress of the situation – I just totally bombed it. I flubbed, and at the end I had a really easy question and my brain just blanked how to do this certain pattern in JavaScript. It’s a basic pattern. (I think you guys will learn learning it?) It’s a module pattern in JavaScript, or a hacked object-oriented JavaScript.

It (the interview process) was like: “do this and that” and I was like: “aaggh...how do I make an object, I don’t know!” That was how I ended up at Mind Body and now I am here before you. That’s my whole life story, starting from the start of my career. That’s the abbreviated version…abridged that’s the word I was looking for.

(Laughter)

Erik

So how did you actually locate Mind Body and how did you approach the job search process in such a specific regional area?

Peter

I was not just applying at Mind Body; I applied for a few jobs. I was torn between working up north because that’s where the tech industry is, it’s like northern California, and my girlfriend lives in San Diego. So I was torn between applying in San Diego, just working here for a year or like going back to San Francisco – which is where I had been in and out of for a while, before that.

I applied for a couple of jobs and actually I got an offer on paper, it was like a better position as far as like salary goes, up north. I decided it was really important to have a good cultural fit and Mind Body is really good about benefits, so there’s an onsite CrossFit gym that does yoga classes every day, stuff like that. It’s got that kind of vibe, people are healthy and I know going into programming it’s very unhealthy.

Mind Body itself is an exception, I drove by the building and I was like: "that looks like a tech company," (laughs) and I looked them up online. That was actually how I found out about Mind Body. I did look at other companies; I have friends at other companies here, tech companies. I didn’t apply for any of those. I have been approached now by them, they kind of compete with each other for talent, so it’s kind of an interesting situation. Another one is Rosetta. But again I didn’t apply for those, I applied for several up north, several in San Diego and then Mind Body.

I got a weird offer working for a contractor for an Angular application that was contracting to AT&T; the entire business was one contract. It paid really well and it was Angular, but that sounds kind of not my cup of tea. Another one was a cool opportunity but the timing was off for San Francisco.

Finding the job locally, what I ended up doing was I found out about the job, I asked somebody who worked there what it was like to see if I would like it and to see if they could introduce me to somebody who worked there so I could figure out, in engineering, what their department was like, the product development department.

I highly recommend the whole personal approach because at the end of the day you’re going to be working with these people. If you approach them on a personal level you’re not just a number, you’re not just a piece of paper, they’re going to take more into account, it’s more honest feedback. You can be more honest when you’re talking to them in person versus "here’s my marketing page, my resume, here’s me marketing myself through my digital portfolio."

Rigorous hiring processes are GOOD.

I contacted somebody, then after getting a "warm lead" so to speak, then I actually applied through their application process, the one where you go and fill out the form and stuff. Pretty soon, they had actually a really rigorous hiring process. Out of anybody their process was the most intense, which actually in a weird way was a positive feedback signal. They were really vetting me. I was like: "oh yeah, cool." Everyone else was like, "you look like you can program...come onboard."

“..I don’t know, you didn’t ask me any questions how do you know I can program...”

Erik

That’s a good point.

Peter

I know it’s a weird perspective to take but it was kind of positive feedback. There were some really gnarly miscommunication between the recruiter and I, but at the end of the day it all came out in the wash. Personal approach, drove by the building, found somebody who worked there, contacted them, got a warm lead.

Erik

Fill in the gap, how did you find somebody who worked there?

Peter

This was a small town I actually Googled on Facebook “Mind Body” and then saw if there was anybody near me who worked at Mind Body. I got lucky and I knew somebody who knew that person so it was like we had common friends and I was like hey, intro me this person. For the one in San Diego I just talked to a guy, I knew a guy who knew a guy, I found opportunity angular developer, I talked to this guy who worked with the person who had the contract with AT&T. That was a warm intro I didn’t even see their online thing, actually. They showed me the online thing after the fact, after talking to them.

The warm leads thing has been way better than cold emailing, although one success cold emailing was a Rails application developer in the marketing department in Apple and I got a callback from them but it was after I already started working. I was like, oh, I’m so curious if I could pass that rigor. It’s like in the marketing department building applications for marketing, but still that would be a pretty cool self-assessment kind of thing.

Erik

That’s something that we’ve talked a fair bit about and certainly are going to be speaking more about it is how do you actually start from your little bubble and figure out how to connect the dots to finding people?

Peter

Yeah certainly, it’s a lot of being OK with just randomly talking with people, I think is really what it comes down to. And recognizing—here’s something I wish I would have known, I sort of treated my interviews—when I first start had really bad imposter syndrome. "I don’t know what I’m doing and I don’t want anyone to find out I don’t know what I’m doing." I can tell you guys specifically coming out of this program, coming out of Viking specifically, looking at how the curriculum has grown even since I did it, you will be better prepared than you think you are.

Confidence in your abilities matter.

It’s really solid, and I think one of the really big strengths of it – I obviously don’t need to sell this to you guys but it’s kind of reassurance to you that you’re going to have this doubt in your mind and you just have to project confidence because we can do the job. Unless it’s something really, really specialized like artificial intelligence programmer in some weird dialect with lists, I would say probably do some homework before you apply for that job but for most web application developer type jobs, most have front-end, backend, web developer, you will be well prepared. You’ll have to work hard, you still have to continually learn, but you’re better prepared than you might think.

That confidence will certainly show in an interview, so two things that you guys might not think to ask that I wanted to share with you now that I have actually interviewed people for front-end junior position. I have gotten to see at least what it’s like to look at somebody who’s really nervous and sweaty and distinguishing between "noise and signal" which I think is the biggest challenge that interviewers face, and nobody’s good at it.

There are three things that play in: the recruiter probably doesn’t know what you’re actually going to be doing. Most of the time — there are other things that are Mind Body specific – these are things I have confirmed with my friends.

The recruiters don’t necessarily know what you actually will do day-to-day, their job is just to get you hired. They get paid on commission – so they want to get you hired. Recruiters are your friend but they don’t know what you’re going to be doing and they might not have an accurate representation of the team you’re going to be working on, things like that.

The people you want to talk to are the actual engineers, the team that are going to be hiring you so that you can fulfill the need they feel. They got some budget so they can now get an extra person to actually complete this job.

Getting past the recruiter is just making your resume look as good as you possibly can within reason – don’t say you’ve done things you haven’t done but don’t be afraid to market yourself. I think that’s something I really didn’t do because I wanted to prove that I could get a hardcore engineering job at a big tech company with just representing myself exactly honestly. It’s something I wish I would have spent a little bit more time being more of a self-promoter with my resume. At the end of the day the only thing that matters is: can you complete the job and can you work with the people that you’re working with, everything is just to figure out if you can do that.

That’s one thing I wanted to say is that recruiters don’t know what they’re looking for necessarily.

Number two: is it’s a field of specialties. It’s a field of infinitely deep specialties, that’s what I’ve learned being in the industry. What you’re learning is like this stack of technology to solve business problems, and at my company there are people who don’t understand, you would think that the site reliability engineers would know what the software engineers are doing, but they don’t actually know – there’s not a lot of interchange.

A lot of the people that are out of college a few years, they have already forgotten the stuff that you’re really worried about now, with algorithms and the whole – they’re not fresh on solving a bunch of programming challenges because they are really deep in their specialty.

Again, at the end of the day it’s about – actually from my two sources – anecdotal sources – but it’s one my experience and two, asking people who are in technology if this is true or if it’s just Mind Body: It’s like this field of deep specialties and what you’re trying to do is be able to do the job you’re trying to get hired for. If you can do the job, which I believe that you’re well-equipped to do at the end of Viking Code School (a quality bootcamp experience) for web application development, then your goal is to represent that as well as you can for actually transitioning into a legit job.

Pre-interview: ASK to connect with the hiring team.

Erik

That’s awesome, so you mentioned that you want to try to talk to the team as quickly as possible. Is that just something you have to wait until you get your past the recruiter or HR person to get to, or is there a way to back into it?

Peter

I talked to an HR person then a recruiter and I asked both of them if I could contact the person I would be working with and they said "yes" and they gave me the email before I was supposed to get it. As long as you can get on that call – the obvious step is be humble about it and just ask. The recruiter I’m working with now makes the job descriptions better but he specifically, our recruiter is really pressed for time and so he’s got to thin-slice people like really fast. He doesn’t have time to think a lot and really understand job descriptions going out and input from resumes going in. We’re tooling with that process.

You’re talking to somebody who is not necessarily going to think: "oh, this person would like to talk to the engineering team they’re going to be working on", but if you ask that they are probably willing as long as you’ve made it to talking on the phone with them. They’re calling you, they’re interested, say can I talk to the engineering team so I can ask them questions to see if this might be a good fit for both of us, something like that. That’s all I did, I got the email of the front-end engineer manager and had a conversation with her via email before the phone technical interview.

Erik

That’s great advice. I have a number of questions but I want to make sure that everyone else here has a chance to ask all of your questions.

Student Q: [Jeff]

I can right away ask a quick question — you’re spot on that the recruiters have no idea what you’d be doing. I am already running into that, so basically my biggest question you talked a lot about how your current job was a good fit because of the culture and just the atmosphere there.

How important is it to find a good culture fit for your first job? Are you looking for something where you’re comfortable or is it more just to get yourself out of your comfort zone and expand, but just to make yourself a well rounded developer from the start?

Peter

That’s a really good question. The obvious cop-out answer is it totally depends on what you want – so the value in that answer is you need to define what you want, right? I have a friend who said I was crazy for taking this job because it’s below market salary and he said “I will get you a job getting paid twice as much.” I said yeah, working 80 hours a week to the bone and weekends and not sleeping, I’ve done that, no thanks. For me the choice was very difficult but it was taking less salary as a tax for a company that doesn’t call you after 5:00 p.m. doesn’t expect you to work on weekends and provides a lot of health benefits.

As far as the opportunity to become a well rounded developer, you kind of had two questions in there, for me that one was surprising where basically I have had the opportunity to do as much work. If I wanted to work 80 hours a week I could. So for me I found a sweet spot for my personal taste and preferences. It’s gotten me into trouble because every time I have been overworked it’s been because I’ve been pushing myself out of my comfort zone and I asked for it. I would have to remind myself, I asked to be on this more difficult project so I could learn something. I didn’t have to learn TypeScript I was never expected to work on the TypeScript side of things, I could have just gone chugging along doing JavaScript but I got to a point where I started getting bored with JavaScript because it was just the same thing over and over, and so I said can I work on this other project, this more modular cooler hotter thing.

They said yes, here’s the whole project. I was like: “oh, OK.” A general response is if you like the culture from a personal level – that’s probably important depending on how important it is to you. The second thing after that is if you can bear the culture, making sure there’s technical talent that can help you grow that you can be mentored by. I have been really lucky to have some really amazing people where they’ve been working and older programmers were senior leads who have been working in the industry for years, they’ve seen it all and they’ve kept up to breadth, so they actually are on the bleeding edge even after that. I don’t know how they’re not burnt out, but those are the people who I can go and if they have time, tap them on the shoulder, "hey, got a question" and then they’d blow my mind with their knowledge.

I think getting a mentor if you want to grow as a developer is really important. That’s been something that has been invaluable that I was missing as a hacker, freelance guy.

Student Q: [Jeff]

It’s safe to say if you were to summarize, if you were prioritize what’s the most important thing is probably just finding a team that can mentor you, everything else is just your personal preference or whatever is important to your values, but just as a developer finding a team that could shepherd you along to where you want to be?

Peter

Yes, certainly and even that comes with some preferences. I don’t like my hand held a lot but I like to have the idea that there is somebody if I really screw things up – which I’ve done – that I can go and wave my laptop at them and say "help me!"

An example of my biggest mess up, so far to date and I’ve worked here now for like nine months, my biggest mess up was I – I have to work in a virtual machine and I really don’t like it. I don’t like working because I have to switch between the Mac side and then the virtual machine to do check-ins using visual studio because it’s a Microsoft stack, very proprietary.

I was building tools to help me be able to use the Mac side of things so that I wouldn’t have to go into visual studio and check in my code. I initialized the Git repository on something that uses what’s called team foundation server, so like Git ignore they have TFS ignore. All of these things instead of Git this or Git that, it’s TF this or TF that and I don’t like it. I am a huge super fan of Git, so I initialize this Git repository so I had this half thing, I read this blog on how to set that up, and then I had to actually check something in using TFS and because of that collision of how I initialized the Git repository inside something that was already basically using TFS’s whole thing which is different than Git.

Git cleaned the repository, meaning it deleted all of the files I had just changed, I didn’t even know I did it. So then when I went to check in the code, just like a push, there was nothing there, all of my changes were gone so I had to run to the senior developer and be like what did I do? He is like you are an idiot, look in your trash folder, and they were there but I didn’t even think to do that. It was something so simple.

Git cleaned the repository, meaning it deleted all of the files I had just changed, I didn’t even know I did it. So then when I went to check in the code, just like a push, there was nothing there, all of my changes were gone so I had to run to the senior developer and be like what did I do? He is like: "you are an idiot, look in your trash folder", and they were there but I didn’t even think to do that. It was something so simple.

I hope that was a good answer.

Student Q: [Jeff]

That was awesome, appreciate it.

Erik

Anyone else have a question?

Student Q: [Andrew]

My name is Andrew, did you really say you work 40 hours a week – is that possible?

Peter

Yeah, it’s crazy. Erik can attest to this, I started taking on more than I can handle as far as hours go, and so starting the job I was in like panic mode, like panic mode super-charged, Silicon Valley-type like caffeinated, got to get things done as soon as they come to my table and there wasn’t anything for me to do like the first week I worked there because they hadn’t set up my environment and all that stuff. It took us a week to setup my environment, they were really slow paced.

Then the Friday the guy who was training me he was like yeah, you can take off early, we’ll get you started on this project next week. You know in "Talladega Nights" where he’s holding his hands, I don’t know what to do with my hands. That was kind of how I felt. I was like – uh, OK.

Yeah, I actually work 40 hours.

Student Q: [Andrew]

That’s crazy. I guess my question is kind of a follow up to some of the culture questions, how do you exactly figure that out? How do you go to a company and through the interview process figure out what their culture is? Do you get enough exposure during the interview process or is that something you just have to know or try to discern from mixed signals and stuff?

Peter

That is such a good question. Short answer, no — I don’t think you can really tell from the interview process, for the same reason they can’t tell if you’re actually really good or if you’re just really good at looking good.

You can tell, I think the whole – the truism is people are the same wherever you go so your intuition for people is going to be right wherever you go. If you feel like you could be friends with these people or if you feel they’ve got something you like, something is attractive I think that’s a good indicator. Certainly there are things I don’t like about my company, I think that’s true for anybody at any company.

You won't always "like" every aspect of the job!

Legacy code, dear lord that is something I do not wish on my worst enemy is some of the legacy code that I’ve had to deal with. That was not something I had ever dealt with before because it was always new code I was writing and that is a talent I regret to have now is fixing legacy code.

That’s not culture though, certain things in the culture is like this company, we’re going from private to IPO, it has a ton of changes so the culture has already changed since I’ve been there. I don’t think I would have been able to tell overall the cultural vibe of the company, if you will, just from the interview. I tried really hard to make that clear that was my intent in the interview and I think that kind of gets you brownie points that you care enough about that to ask.

Weird stuff being on the interviewer side is people don’t ask about that most of the time.

Get curious, go deep, ASK questions in interviews.

I have interviewed several people now. "Do you have any questions?", we ask them, we leave 20 minutes at the end of an hour long interview – do you have any questions and a lot of it starts with awkward silence or their questions are very topical. If you think ahead of time of that, cultural questions and make it more of a conversation between people rather than an interchange of entity and potential employee. I think one it makes the interview a lot more pleasant for both parties, two in a weird way, it kind of earns you points because you care, you are projecting that you care, but the more important thing I think you should do is then you’ll actually find out that information that you’re asking. Is this a cultural fit.

Every question that was a cultural question they asked me I reflected back to them and say what do you guys think? The cultural question is like if you had to pick out a pizza for this whole team what would you order. I laughed, I would ask you guys what you want. Why I would I pick out a pizza and just force my pizza upon you. They laughed and I was like what pizza would you make me eat, is what I asked them? They felt it was funny, so it leads to that more casual interchange and I think that’s a really good indicator.

If I had said that and they didn’t laugh I probably wouldn’t have wanted to work there. If they weren’t down with my weirdness they I would have been like okay you guys are really serious and I am probably going to get fired if I work here.

Student Q: [Andrew]

That was a great answer, thanks a lot.

Erik

Other questions, other questions?

Student Q: [Andrew]

I have another one, just a quick one. How hard was it to transition from Viking, I know that you worked in your startup but just in the context of BootCamp, how well was your transition into the real world of coding?

Peter

Difficult for reasons I wouldn’t have predicted. I thought it was going to be like: "oh, I’m going to have all these technical challenges." I felt like: "oh, I’m going to have to flatten an array of unidentified numbers and letters and symbols, or I’m going to have make and design some algorithm that runs in linear time, or something like that." The technical challenge, the only time I had to think about algorithmic complexity was this really weird requirement of basically like nested arrays. Make sure it just doesn’t crash the CPU when you’ve got 10,000 items that we’re sending down, optimize it that way. That’s the most complicated thing.

The complications came from the environment, the massive code base – massive. I haven’t seen probably – I’ve seen probably 10% of all of the code that exists in the company. There is one JavaScript function as far as with that legacy code that was over 3,000 lines. I was going to say 5,000 but I think it got cut down – one function 3,000 lines of code.

Imagine you have to go fix that, that’s the environment that you’re in, you’ve got new tools, you’ve got this new process. They use Agile but it’s their own flavor..." and I talked to another friend and was like what is your Agile process? It’s completely different. People say Agile and really the only thing that stays the same is velocity points and scrum, and maybe tasks on some version of the board.

Bootcamp-to-job transition challenges.

I have seen three different flavors just talking to people, so the hardest part was getting up to speed with how everyone interacts, the lingo that they use to describe things, the software else, the massive code base, fixing bugs in code someone wrote four years ago that is no longer there, I can’t even ask them about. Fixing code that is like from the start of the company, which is like why? It doesn’t even need to exist there anymore, that was the biggest challenge was getting my head in the environment and getting up to speed with all of the tools that were unfamiliar to me. That was the surprisingly most difficult challenge, and then as far as if you’re willing to take the time to really learn what you’re doing, what specifically you’re asked to do I think, at least for me, that was a relatively smooth process, especially like I said going from 80 hours a week plus to 40 hours a week.

When I first started I had a lot of time to just think about getting up to speed and learning, for instance knockout, which is an older JavaScript library that kind of lost out, but we’re still using. I can’t talk about it but we’re using it in a really cool way. That kind of like learning to work on, that was learning the basics of knockout and stuff, but the hardest part was the environment.

Student Q: [Andrew]

Thanks.

Working in startups versus established companies.

Erik

I have a question based on something you said way back in the beginning when you were talking about working in the crazier environment, working in the "wild startup."

You had mentioned there was a big difference between developing and engineering and in the way you were sort of doing the caffeine-fueled development versus actually learning about engineering. Can you talk about what some of those contrasts are and how you learned the engineering side of things?

Peter

Certainly, I’ll say one thing, QA, Quality Assurance or Analysis. I only call it QA, Quality Assurance, they have made me at least twice better developer, engineer, thinking through edge cases because it is their trained job profession, what they do for eight hours a day, is breaking your code. I don’t know if you guys have gotten to do that yet, breaking other people’s code. Doing it yourself you just think of the use cases that you came up with. You think: "OK, well I am for this use case so let me make sure the use case I wrote directly for doesn’t fail."

I have to think about, I think we support the double digits of languages, we have a huge number of users that are clients. We’re a B2B business, I never said what Mind Body does, Mind Body is a wellness software which means gyms, yoga studios, and anything in between, martial arts studios, salons, anything you can think of that’s like wellness, making yourself feel better. We serve their business needs.

If you have ever seen Mind Body’s consumer applications, the mobile version just got good, the web version I’m sorry...if you have ever had to use that, the consumer web experience from Mind Body is a very old portal and it’s unfortunate if you use it.

That being said we have to think about the business and then the business’ clients, and so we have millions of users and a whole bunch of different languages and they will come up with using the software in ways you would never think that someone would try to use it in and QA’s job is to replicate that so that whole working as a hacker developer in a freelance, here is somebody they’ve got 20 people they’re serving, I build exactly what they want they serve those 20 people a day and they pay me because they’re making enough money to make that work.

Those numbers are all fake and wrong but the point is it’s not massive scale, it’s not just like running a statistical experiment on your software with a bunch of people randomly pressing keys, we actually had a problem, a server got fried because the cat on a keyboard test, which is just holding down enter because we didn’t have debouncing. We weren’t stopping the submit of a form and it was just submit infinitely as many times as the keyboard would trigger the event.

Stuff like that makes you a better engineer because you have to think through end cases, you’ve got design things instead of being like what do you want, let me build it really super Agile, one piece at a time. It’s more like we have these big needs, they’re known, we know what data we’re processing, we’re building a feature for these people how can I make this work on release instead of the most basic version. Well it’s still the most basic version but something that’s broken and the client just isn’t going to find out about it because they don’t have millions of people using it. That’s the big transition, it’s really thinking through requirements at a deeper scale than just jumping right into coding it up.

Erik

I think that applies on a high level in a lot of different ways, learning process. Well cool, are there any other questions out there as we begin to draw to our close?

Student Q: [Andrew]

I have another small one since my first one was just an expression of incongruity and not really a question. Do you pair program at all in practice where you are, I know that’s a cultural thing? Is there a culture of that in your company?

Peter

Pair programming, we don’t do it as much as some people. I think some shops just all pair programming but we certainly pair program especially, it’s more someone has some area of expertise, you are working on a project that needs their help, it’s just easier to get in the same room in front of a keyboard and pass it back and forth. Yeah, I love it, watching other people – I’m sure you’ve heard all the benefits and I’m sure you guys have done it. If you’re still doing the whole driver navigator thing, we don’t have phone programming, it’s: hop in the room and for the next hour or two let’s write this together. I love it, it’s great.

Student Q: [Andrew]

Cool, that’s all we do. It’s a good tool.

Peter

Yeah, I’m getting nostalgic thinking about some of the bugs we ran into pair programming at Viking. Those were fun.

Erik

Dark days, dark days.

Peter

There was one where we spent – I’ll just out myself about this, I got so much crap for this. We were using, I don’t know what part you’re at but we were doing the dean book and we were using code I had written individually and code other people had written individually and smashing it together.

Erik

I don’t know if you could call what you had written code.

Peter

I had forgotten an opening div and there was a closing div and we were trying to write integration tests and they weren’t running. We were on the last one and we spent four hours debugging and it was three people pair programming and one of the people was like, “wait a second does this div even have an opening tag? Is that what is causing the problem??”, because we spent four hours and I had written a div, I had deleted it and forgot to take out the ending tag so the integration test was telling us no. They were pretty mad about that, deleted it and all of our tests cast. That was the most embarrassing, it was not very good code.

Erik

But it’s better now.

Peter

Oh yeah, I don’t think I was a very good Viking student but I’m a lot more confident now in my engineering capabilities.

Erik

We have one last question from outside here that I have been sent along, it’s what role is testing playing in your workflow?

Peter

This has been a long discussion because I have been advocating for bringing tests into the raw knockout side. It’s on the TypeScript side because it better lends itself to that, but there’s a lot of ideas on how to write JavaScript that are bad or wrong or like just different, so it’s hard to write across the board unit tests. On the TypeScript side we don’t do TTD but we’re writing unit tests, some people are advocating for TTD, they like it, but most of the dev’s on the TypeScript side are like we don’t really want to do that, we’ll just write our unit tests post processing.

Also I have a quote that really inspired me when I was in Viking, I wanted to share with you guys. I don’t know if Stacy Tusett came by but she came and did a talk to us and showed us how cool programming was when we were first getting started, and blew our minds. One of the things she left on which I thought was really funny, it’s really good life advice and I think of it often.

On creating ease around what you do.

It’s so simply put but you end up in a lot of situations where okay, on the deeper level if you’re pushing on a problem and I’ll think of that sometimes. I’m really caught up in my own solution I’m starting to freak out about it because I need something done. Just stopping, stepping back and like taking a breather and not thinking about a solution for a second and then coming back to it with fresh eyes has been one of the most useful tools in my arsenal.

I wanted to just end on that, if you’re doing something that makes you sad, stop doing it.

Erik

I don’t think I could do any better than that. Thank you so much Peter for chatting with everyone tonight. Thank you to everyone who is watching either now or later and this has been the Viking Codecast, Peter DePaulo, my buddy online, former student and JavaScripter extraordinaire. Thank you all very much I hope you have a great day, evening, morning or night, and we will see you guys next week.

Peter

Thanks for your questions.

Erik

Have a good night.

Contacting Peter

GitHub

Twitter

LinkedIn

From n00b to ninja, we'll help you to become a developer
Subscribe to get expert guidance on learning, building, and getting hired delivered right to your inbox each week.


We guarantee your privacy 100%. Your information will not be shared.
NOTE: Comments are disabled outside of the "https://www.vikingcodeschool.com" production environment to prevent Disqus from assigning the wrong URL and forcing us to map away from `localhost:3000` each time.