Episode 022: You Are An Asset


Jessica Kerr | Coraline Ada Ehmke | Sam Livingston-Gray

Guest Panelists:

Ryder Timberlake: @rydertimberlake and
Jacob Stoebel: @jstoebel | jstoebel.com

Show Notes:

00:16 – Welcome to “Mob Programming” …we mean, “Greater Than Code!”

Support us via Patreon!
Get instant access to our Slack Channel!
Thank you to our newest $50-per-month-level patron, Bryan Karlovitz!

02:39 – Origin Stories From All!

Tim Ferriss and The 4-Hour Workweek

12:37 – Work/Life Balance and Ideal Work Environments

Stockholm Syndrome

If you’re looking for a hilarious podcast that focuses on issues that software developers face, such as getting fired, pay raises, strategies for pushing back on bad ideas, and even stock options, check out Soft Skills Engineering!

Episode 10: Mentors and Stock Options

16:50 – Technical Interviews

20:41 – Computer Science Degrees: Are they worth it?

27:42 – Compulsions to Know: Contempt Culture

Aurynn Shaw: Contempt Culture

The Zens of Python and Ruby

34:12 –  Gatekeeping in Tech

37:11 – Technical Interviews (Cont’d)

Pair Programming

Please leave us a review on iTunes!


SAM:  Hello and welcome to Episode 22 of Mob Programming. I’m your host, Sam Livingston-Gray and with me this morning is Coraline Ada Ehmke.

CORALINE:  Yes, Mob Programming is the name of our podcast. I fully believe you, Sam and I will not argue with you under any circumstances. It has nothing to do with a tweet that you have prepared about me and given me a screen capture of, that you will tweet if I disagree with you.


CORALINE:  Who else do we have? Oh, we have Jessica Kerr with us today.

JESSICA:  Thank you, Coraline and I am thrilled to be here today with guest panelist, Ryder Timberlake.

RYDER:  Thank you, Jessica. I am also thrilled to be here with guest panelist, Jacob Stoebel.

JACOB:  Thanks, Ryder and collectively, we are…

ALL: Greater Than Code.


CORALINE:  Oh, did I messed up?

SAM:  Together we are not on cue.

JESSICA:  Totally works.

CORALINE:  You might notice, we have a couple of guest panelists today. We have Ryder and Jacob with us. How did we select Jacob and Ryder? Does anyone know? Well, as you may know, if you’re a regular listener of this podcast, if you pledge on Patreon.com/GreaterThanCode at any level, you can get access to our Slack community and this week our guest had to cancel so we decided to reach out to people in our Slack community and see who is interested in co-hosting with us.

We did a little lottery and it was adorable, Mandy’s daughter picked names out of a hat and that’s how we ended up with Ryder and Jacob and we are so thrilled to have them with us. If you want the opportunity to maybe take part in a future show or if you like the idea of being somewhere where you can talk about serious things and often, do fun things like that, go sign up. You can sign up for as low as a dollar a month then join us and join our wonderful community.

Speaking of Patreons, we want to thank Bryan Karlovitz who is our newest $50 sponsor. Our show is 100% listener funded. We are open to corporate sponsorships for the right companies. You can contact us about that but at present, we are 100% listener funded and we really appreciate people who donate at any level but Bryan Karlovitz at the $50 level is going to be a big help to us so thank you so much, Bryan.

JESSICA:  Jacob, we like to start the show with origin stories and you haven’t been on before. How did you acquire your superpowers?

JACOB:  I work for a college right now. I was hired in a job that’s a little bit different from what it is right now. It sort of evolved. Basically, I was hired to be an Excel data entry person. I was hired because I had some competencies in Microsoft Excel. After working for about six months or so, I found that the systems that they were hiring that work manually were really unwieldy and at the same time I had been learning Python and doing some neat things to automate really boring tasks.

I approached my boss and I said, “How would you feel if I created some software that could automate what we’re doing?” Fast forward to four years later which is now, I’m managing a Rails app that has completely overhauled this big data system for the department I work for. I guess, in a way my origin story is still taking shape. I write software for most of my job but my job title does not say software developer in it. I would like for it soon but that’s where I came from.

JESSICA:  Wow, so you automated yourself out of one job and into another?

JACOB:  Yeah.

JESSICA:  And then another?

JACOB:  Yeah, basically.

SAM:  That is the best. I love doing that.

CORALINE:  If it gives you any hope, I have a dear friend named Jack who pretty much was doing the same thing. He worked for a mass mail marketing company and hated the job. He was doing data entry too, started programming and now he’s a pretty well-known frontend engineer. He worked his way out of that job and automated his way out of that job so there’s definitely a path forward for that.

JACOB:  That’s really good to know. I am mostly self-taught. I also live in a small town so in terms of pairing up with other developers is a thing that I have to drive 45 minutes for to meet other people.

CORALINE:  — Is your friend.

JACOB:  Yeah. It’s just encouraging to know that because for standing on this side of it, it feels like a canyon that I’m hoping to traverse soon but it is a canyon nonetheless.

JESSICA:  Yeah, based on your work for a college and your title doesn’t say software engineer and you evolved into this job, I’m going to guess that you’re severely underpaid.

SAM:  That’s extremely likely.

JACOB:  Thank you. I’m going to take that as a compliment. I’m going to be a dad soon and I won’t lie. I hope the money situation will improve as well because it’s nice to have.

SAM:  Yeah, if you can’t have sleep, you can at least have money.


JESSICA:  Parenting as a software engineer.

JACOB:  That’s sort of in a nutshell. It’s like ask me again in six months because —

RYDER:  I think, it’s exciting to hear.

JACOB:  — It’s still happening but that’s me.

JESSICA:  Ryder, how about you? How did you get to software and become… Wait, what have you become?

RYDER:  An automation engineer at Salesforce. When I started out, I had worked a number of jobs I was pretty underpaid and overqualified for. Although, of course, if you’re not working, you’re not overqualified for anything so I had a rocky beginning to mid-career trajectory where I was just working at places. I was also inflexible about moving geographically so I was working at places that met that criteria. I was always attracted towards more autonomy, creative lines of analysis and thinking. I wanted to be a musician. I tried to be an artist a couple of times professionally, which is hard to do. I’m sure some of you have experience with that. Eventually, it seems like a profitable thing to pursue. I actually came to programming by way of stock trading. I did stock trading first and programming is a little bit less stressful.

JACOB:  Because you can always undo, right?

RYDER:  Yeah.


SAM:  Well, maybe.

RYDER:  Exactly right.

CORALINE:  Source control for the stock market.

JESSICA:  Seriously, in programming, we have the ultimate power. We can save our game.

SAM:  The next person who says block chain is fired, by the way.


CORALINE:  The thing you said the next person and otherwise, right? I’m old enough that my first job in tech that my title was webmaster, in 1994.

JACOB:  Fire GIFs.

CORALINE:  I was more tasteful than that. I worked for an engineering company and I don’t have a traditional background at all. I sort of did and I sort of don’t. I started programming at seven and by twelve, I taught myself assembly language because you couldn’t make high-res graphics go fast using any other language. I always knew I wanted to develop software for a living. Then I got to college and I took my first CS class and it bored the hell out of me.

Our semester long project was to write ATM software in C and I was like, “What am I going to do with the rest of my time?” I was like, “If this is what software development is like, I guess it’s not for me,” but I kept hacking on side projects. I went to work for this engineering company. I was actually doing media relations. I built them a database for tracking press releases and stuff like that so I was still doing tech stuff but not really. But I knew all the geeks because we all smoked together. I had a good relationship with the software developers and sysadmins.

One day, when one of them comes up to me and was like, “I don’t know if you heard but the company’s starting a web team.” I was like, “That’s really cool. Yeah, get on the web. That would be great for the company,” and then they said, “What do you think that’s going to do for your career?” I’m like, “Career? I don’t have a career.” But that was the start of my career. It was interesting. From my interview, I had to study how to do tables made of [inaudible].

SAM:  I remember. Those were useful, as long as you know how to slice your files appropriately.

CORALINE:  Exactly.

RYDER:  That’s excellent.

JESSICA:  I majored in physics in college because it sounded hard which is the best interview answer. It’s actually true. That was silly and it sounded hard. It wasn’t hard though.


SAM:  Really? I have a really hard time with it.

JESSICA:  I started at bachelors and it depends a lot on your teacher. We had good teachers but physics, if you want to go into that, you just have to have a huge passion for it because you’ve got to go to school for 10 years and you’re going to have to move around the country and look for positions and move around the world and just hope to find something that let you do research in that field.

I was lucky enough to get a programming internship to a friend of my aunt’s during college and I was like, “Wow, this is pretty sweet.” I’m pretty good at it. It’s a lot of fun. I got to program in this mapping software. It was ArcInfo at GIS and like make maps. It was super fun. This is for FedEx. I was like, “Wow and you get to go home at 5:30 and there’s no homework, right?” There’s no papers and projects hanging over you that you’re supposed to do. I’m like, “I could totally do this.”

Then I found out that I could get a job anywhere in the country with my bachelor’s degree and make $40,000 a year in 1999. I was like, “Sweet. It’s good, this physics thing,” and I did and that’s worked out. I’ve been developing professionally for 15 years. I no longer have the property where I can go home at 5:30 and forget about it but that’s a choice because I’ve discovered the software is incredibly fascinating and the people in software are incredibly fascinating. Now, I do not put it down. Well, okay, I do put it down at six o’clock but only for a couple hours so my kids go to bed.

CORALINE:  Hopefully, you’re making more than $40,000 a year now too. At least, 45, right?

RYDER:  Yeah, nine-to-five was a luxury worth relinquishing for how cool software is for you.

SAM:  That’s kind of like that Tim Ferriss’ The 4-Hour Workweek thing where it’s very easy to say that you only work for hours a week, if you redefine everything that you do as work as not work.


JESSICA:  Especially now that I’m at Atomist, I’m doing the stuff that I used to do in my free time and I get to do it full time so it really blurs the line now because it used to be, I worked until six. Then after I come back and learn, stop and read and write blog posts and make talks — mostly make talks — but now, that’s all the same thing. I can work on my talks in regular hours and I can code on the weekends and it’s just all blurred together. The work-life balance doesn’t seem like a problem when your work feels like life.

CORALINE:  I could get the same thing working at GitHub on the team that I worked on rebuilding the entire [inaudible] community management features. I’m basically getting paid to do the stuff that I was doing anyway, except now I have leverage over the entire open source world, which is a definite advantage but I have a dream job and I get all these recruiters that are like, “There’s this hot new startup,” and I’m like, “Do you know where I work? Do you have any idea what I do and what that means to me? Thank you but no.”

RYDER:  Now, what you were describing, Coraline about the ladies room at GitHub, that sounded really inspiring and like a wonderful and supportive place to be.

CORALINE:  It’s great. My team member are amazing but my interactions with other people outside my team have been pretty good as well like really good with a couple of that-was-weird moments but overall, really, really good. The culture is definitely changing. for those who didn’t know what that reference is about the bathroom, on the engineering level at GitHub HQ, there are posted notes and Lisa Frank stickers and a bunch of Sharpies and we leave encouraging messages for one another and we ask each other questions. One person’s even doing like the [inaudible] adventure story. There’s a sword in front of you, what do you do and it’s like, pick-up the sword and it’s like, in columns down the entire door. It’s so cool.

SAM:  That’s amazing.

RYDER:  The game master is coming back and writing the bits or different people also being the game master?

CORALINE:  No, the game master is coming back. Judging from the handwriting, it’s the same person coming back and doing the responses.

JACOB:  Is it all set in a bathroom?


CORALINE:  It actually starts out in a laboratory, not a lavatory but a laboratory.

SAM:  Come in a place to find sword just lying about.

JACOB:  Has anyone ever encountered a time because I have, when at first the work-life mixture was a good one and in other times, it didn’t work out so well?

RYDER:  This is the same job?

JACOB:  Not this job, no. I come from the arts world, theater specifically and in that world, nonprofit theater is like, “Why would we be doing this?” If not because we loved it like there’s no other reason. I think what followed from that was while we have to go to the [inaudible] together, we have to do XYZ, we all have to sort of live together too. At some point that became, I don’t think essentially a bad thing but it just turned out to not work for me and I’m wondering when does it work and when does it not? When does that work-life blurring become negative?

CORALINE:  I think to a degree there’s a Stockholm Syndrome because it kind of sneaks up on you and you’re like, “Oh, I’m new. I have to work extra,” and then that becomes a new normal for you and you forget the fact that you’re working 60 hours a week.

JESSICA:  And then the next new person starts and looks at you and thinks that’s the expectation.

CORALINE:  I had a job where people started doing commits on weekends. I actually went to management and I was like, “You need to tell them to not do this because this will become the new normal.”

SAM:  And then did you have to explain why that was a bad thing?

CORALINE:  Yeah, and guess how effective it was?


SAM:  How long did you stay in that job?

CORALINE:  Maybe 14 months.

RYDER:  Yeah, not surprisingly.

CORALINE:  Long enough for my stock options to bust.


SAM:  Yeah, I had the options conversation with a potential employer recently and I think I might have hurt some feelings when I basically explained that I value options at zero because there are just so many variables that I don’t even want to think about it.

JESSICA:  Lottery tickets.

SAM:  Yeah, you’d rather buy me lottery tickets because I can calculate the expected value on those very easily.

CORALINE:  I worked for about six or seven startups but one of them actually did payoff and it did payoff pretty big. My strike price was $4.76 and I sold the stock at $24. That’s just once.

SAM:  Right. Speaking of stock options, I was listening to another podcast called Soft Skills recently and they actually had a really interesting episode. I think it was Episode 10: Mentors and Stock Options. They had a really good explanation of stock options and how they work. If you got lost when, Coraline said strike price, go listen to that. It’ll clear a lot up.

JESSICA:  Sweet. Shout out to Soft Skills Engineering. That’s another podcast that you’ll might want to check out. If you’re looking for a hilarious podcast that focuses on issues that software developers face such as getting fired, pay raises, strategies for pushing back on bad ideas and even stock options, check out Soft Skills Engineering at SoftSkills.io.

Jacob, you said that you are working as a software engineer but you haven’t yet acquired software engineering job in the traditional sense so you are going to have to go through the dreaded hurdle of your first technical interview.

JACOB:  Yeah, I’ve read about it and thinking about it, trying to at least mentally prepare myself or emotionally prepare myself. It’s almost like a system of reproduction like we have CS degrees that they went through that ringer to get their job and once they feel like that is a reasonable expectation for everybody, they’re going to subject the same people do it so we end up with more CS degrees. It’s a little scary. I’ve taken a few CS classes but put together a [inaudible]. That would be tough for me.

CORALINE:  I think it’s important to note that interviews are two ways. You will learn as much about what the company values from the coach on they give you, the abstract or the algorithm and so on or does it reflect the work that you’re actually going to be doing because I have never had to invert a binary tree in my entire career. I have never had to write my own sorting algorithm because my language provides a sort method. These quiz questions, they tend to be too CS-y for me. Like I said, I’m a dropout and if that’s what the company values, I really don’t want to work there.

JACOB:  Yeah, fair.

SAM:  Yeah, it sort of says that the engineers that are haven’t really thought at all about interviewing so they’re just going to go back to standard nerd gate-keeping behavior which is horrible.

RYDER:  Yeah definitely. I think you can have some of that stuff in the interview but it’s the main component. That says a lot, Coraline definitely.

CORALINE:  Yeah. How many times as an engineer actually write code on a fucking whiteboard. It does not happen. It’s like saying, “Oh, if you would design a programming language, what would it do and do it on the whiteboard.” I’m like, “No, I’m not going to do that.” I’ve actually turned away jobs because of programming exercises they expected me to do. I got one exercise from a company that a very prominent Rubyist works for, where they’re like, “We want you to complete this within one hour. We want you to do your first commit and then your last commit. We’re going to look at the time difference between them.”

Then I’m like, “If you value me being able to write a really, really good code in one hour, you’re not giving me time to test, you’re not giving me time to refactor. Fuck you.” I’m so sick of that and that sets such expectations and sets the bar so high that people from non-traditional backgrounds get filtered out of jobs where they could really be a valuable asset. They could really bring some different thinking to the table but because of this monoculture, it’s like, “I know these cover things because I have this CS degree and I took an algorithm class and I think everyone should think exactly like me and everyone should be a robot just like me.” We’re keeping people out that deserve and it works really hard that they deserve to be in.

JESSICA:  People who are good at different things than you are, as supposed to using the interview to make yourself feel smart.

RYDER:  Yeah, and people who could help us solve cultural problems.

SAM:  As the representative of the computer science degree holding population, I would just like to say that all that shit is bull crap. I had a really good time in some of my computer science classes. I did all the data structures stuff. Side rant: I did my data structures homework in Python first and homework took me about four hours and I did a TDD. Then I would take the thing that I’d implemented in four hours in Python doing TDD and I would just try to reimplement the solution with very few tests in C++ or Java. I kept track of how long it took me and the minimum multiplier from going from Python to Java was about 5x. Going from Python to C++ for me, the worst one was 9x.

I was like, “Why am I doing this? It took me four hours to do the homework and then I spent like 25 reimplementing it just because they didn’t want to read Python. What the hell?” I mean, I could rant for hours about how CS has taught but I’ll give you the brief version. It’s just that there’s a lot of valuable stuff in computer science and I feel for the people who are designing CS curricula because they’re trying to serve people who are going to go into academia, they’re trying to serve people who are going to go, like a big employer out here in Portland as Intel. If you’re going to go into chip design, you need a different set of skills, perhaps than somebody who’s going to go into web development so they’re trying to meet a broad range of needs, at least in theory.

But then they have this one-size, fits-all curriculum where they start everybody off with C and C is pretty frustrating. But when I started in on C++, C looked really good. It was just really hard to get my head around and I’m like, “Why am I getting all these fucking no pointer errors?” I basically feel like there’s an element of hazing that goes on. It’s like I learned this the hard way and I feel now I need to make you prove that you can go through this so that I don’t feel like my time was wasted. Maybe that’s a little unfair, I don’t know but that’s how I feel about it when I’m super cranky.

JACOB:  Yeah, or me worrying that I have a CS degree and I learned a lot of C. Me worrying that learning all that C maybe isn’t quite as valuable as it was 15 years ago.

RYDER:  Right so I have to assert this upon the world.

JACOB:  Yeah, and it’s not that C isn’t valuable. Like you said, it’s incredibly valuable but not in every state. I work in a college and the department I work in is as a teacher training so we train school teachers. My boss has some really, really interesting things to say about education theory. One of them, maybe you’ve heard it too, was the idea that we should be meeting kids where they are and that’s the starting point and then help walking with them as they go to where both of us want to be.

I think like the text stack, like we have the microchip at the very bottom and then we have a lower level language like C sitting on top of that and then maybe we have an interpretative language like Python, like you’re saying Sam. It seems to me that the theory that we need to start learning about what’s going on deep down inside the computer and work our way up, it’s really counterintuitive. We need to start with the user who is interacting with higher levels things and then work our way down to first of all, learn Python and then we’ll learn what Python is doing under the covers. “Oh, it’s C,” and then what’s going on even lower down than that so it’s like starting with the learner and getting down to the technology as opposed technology first.

CORALINE:  I think one of the advantages of that kind of approach too is that a lot of people who get into programming, they couldn’t through PHP because maybe they’re in high school and they have a WordPress site and they want to customize it so they learn PHP and they’re like, “Oh, programming is pretty cool. I think I’ll go to school and maybe get this degree,” and the first thing they see is C and has no relation at all to their idea of programming and that’s going to scare them away.

The other day, I was at Northwestern University. They have just night labs program, KM [inaudible], which is a collaboration between the journalism school and the computer science department to work on interactive storytelling in journalism. It was like a round table discussion. I was the guest and one of the students, Mr [inaudible] was like, “I think the thing I’m looking forward to most in professionally doing CS is applying the scientific method to everything I do. When I do a feature, we’ll do AB testing on the feature to see if the implementation was good.” Now, I had to tell him —

SAM:  Oh, dear.

CORALINE:  — That happens on the frontend UX/UI stuff but that does not happen anywhere else and I’ve never had to apply the scientific theory to anything I do. I’d rather —

SAM:  Debugging.

JESSICA:  I’ll do all the time.

CORALINE:  Yes that’s true. But in terms of the features that you write and like, “This product manager has two different ideas for how we can implement this so let’s implement them both and see which one really works.” That simply doesn’t happen. In short, I think that we should have computer science degrees for people that are new to computer science-y things and we should have software development degrees where they’re taught practical skills like actual methodology, pair programming, source control and things that you’ll actually use in a job as a software developer.

RYDER:  But all of those ideally would have a heavy component opinion of working with actual people.

SAM:  Yeah, that would be good. I actually lucked out and I got to take a class in extreme programming from a person who has my undergrad advisor and James Shore who is well-known in the Agile community. That was a super fun and super hard class. I actually almost quit it on the first lab day.

JESSICA:  [Laughs] Did you get a cranky partner or were you the cranky partner?

SAM:  Yes.


JACOB:  I think we’d all agree that there’s use in being exposed to, not necessarily computer science but thinking like a computer scientist. I hope there’s value in that and it’s how do we get to a place where we can have both. Let’s think about like, “Let’s approach this scientifically,” and let’s think about being nice.

RYDER:  I laughed because of how both seamlessly intuitive, that should be for us and how much it’s not and how much that would really advance the field, if that were the case.

CORALINE:  There was this great series of tweets last week that a lot of people participated in and it was basically like, “I work at X doing Y and I still have to Google Z.” I thought that was really great because these were, in many cases, pretty prominent programmers confessing and admitting for the benefit of more general people that you don’t have to memorize all this stuff and it’s okay to look things up and it’s okay not to know everything. Don’t be intimidated by not knowing everything and I thought that was really great.

RYDER:  I think that is great and I think so often, we feel like we have to know. I know this is a topic that you’ve discussed on the show before. There’s this compulsion to know and not to be able to put out that you don’t know and rest in that and have people look at you and be invariable like 20% or 50% of tech audience who would look at you and say, “Wait? You don’t know?”

SAM:  Let’s talk about contempt culture.


RYDER:  Let’s talk about contempt culture. It’s toxic and bad.

SAM:  For listeners who are new to this concept, Aurynn Shaw wrote a wonderful blog post about contempt culture and she’s recently followed it up with talk that expanded on some of those ideas that I have yet to watch. But her basic thesis is that all of this stuff that where we make people feel bad for their technology choices is essentially shaming people and discouraging them from participating. It’s a gate-keeping behavior, it’s toxic and it’s surprisingly pervasive.

We were talking in the pre-call about using Python versus Ruby and how they’re basically the same language but there are some cultural differences between them. Even in that short conversation where everybody’s friends here, I could see that we were coming close to that edge of there’s critique of the language itself. There’s discussion of the differences between the cultures and then there’s this judgment. That judgment, I think is the thing that as programmers, we tend to do a lot more than I think we should.

CORALINE:  I used to be really contemptuous of JavaScript. But what I say now is that JavaScript doesn’t make me happy so I don’t want to program in JavaScript and that’s not a judgment on the language. It’s not a judgment on the people who enjoy the language. It’s a reflection of my relationship with the language which I think is not contemptuous and is perfectly fine for me to talk about.

RYDER:  Yeah, you’re not injecting baggage into it. You’re not saying when you use JavaScript, don’t you know that it does X, Y, Z with Types. You’re not making any kind of judgement about the person who chose to use it.

CORALINE:  Yeah, exactly.

JESSICA:  Yeah, we can make our opinions about us because, really almost everything we do is not about the person we’re speaking or the person that we appear to be reacting to. It’s almost always about us in our experience, in our context and this language is at the same way.

JACOB:  There’s a link I like I have taped to door. People in the Python world now that’s in the Python. If you open your Python Rattle and type-in [inaudible], that’s what you see and it talks about sort of values. [inaudible] I don’t know that constitute Pythonic code or idiomatic Python, things like beautiful is better than ugly, flat is better than nested, readability counts. Somebody wrote this out of Ruby, which when you put them side by side, you see these counterarguments that are like, “Python says that simple is better than complex.” The side of Ruby said, “Simple is boring.”

JESSICA:  Seriously?


SAM:  Oh, yeah this is very tongue-in-cheek. It’s quite cute.

JACOB:  And what it sort of reveals to me, they’re kind of is a little bit of touching on, flirting with contempt in this post but I think what it’s also revealing for me is we put forth the ideas that Python thinks this and like how could this not be true. But then you make a counterargument that’s like, “Oh, right, they’re kind of is a counterargument to that. Why does everything have to be simple?” Maybe there’s some joy in writing something that’s a little bit more expressive, for example.

RYDER:  Sam has just posted to the chat that its tradeoffs all the way down and I couldn’t agree more. There this dangerous and pervasive idea that there is a best way to do thing and that there exist best practices, rather than a best way to do thing in a given context or good practices or best practices, if you happen to have built the other stuff this way.

SAM:  I think that the strongest statement we can possibly make that is fair is that there’s something is the best tool for you right now.

JESSICA:  Or even just a good enough tool because that all right. You’re not comparing everything you know. We haven’t taken into account every possibility. It’s just good enough.

CORALINE:  Yeah, I do a lot of artificial intelligence work on the side like a passion project of mine to get a program that understands and creates metaphors, which is not a simple problem. People are like, “Did you do that in Lisp?” I’m like, “Ruby.” And they’re like, “Ruby’s terrible for that.” I am like, “But I am fluent in Ruby and I can execute on my idea without thinking about syntax so it is the most natural place for me to do it. It’s the best job for me at this time.”

RYDER:  Yeah, absolutely and once you’ve built it in that, you could take it to a Lisp or whatever. It pains me that we don’t have more people who are really robustly polyglot and really robustly unconcerned with what languages people should do. It little bit touches on what we’re talking about as moment ago and what Greg posted to the chat, this sense of the role for a learner should be you adopt the context of the learner and you’re this spotter at the side of the trampoline and you’re making sure that your learner doesn’t do any crazy talk that might hurt themselves with.

JACOB:  Yeah, that’s a great analogy.

JESSICA:  The more languages you learn without exerting, “That’s just wrong judgment,” then the wider your perspective get, the more approaches you can bring and the more perspectives you can understand when you’re teaching. Like Jacob said, as the teacher, it’s your responsibility to adapt the context of the learner.

CORALINE:  Someone mentioned the concept of gate-keeping and I think that’s where I’m going back to. Gate-keeping is this notion that there are authorities with opinions and you have to either agree with their opinions or get their blessing to have a different opinion before you can be right on the internet. Gate-keeping takes a lot of different forms. Gate-keeping is a term that is used with transgender people to reflect the number of hoops you have to jump through to actually get treatment, all of the letters you have to get like for my passport, I had to have two letters from my doctor which is ridiculous.

But gate-keeping in tech, I think is just as insidious because you have the self-appointed leaders or self-appointed expert who maybe did something interesting five years ago or 10 years ago or maybe have the luxury of being paid to do open source and their opinion matters more than anyone else’s. If they disagree with you and they disagree with you publicly, your idea is just treated as shit, right?

RYDER:  Yeah, and also they’re not being held to the same standard, Coraline. Their ideas are not being put under this microscope in the same way.

CORALINE:  Exactly.

JESSICA:  I was thinking about this just yesterday. The concept that an idea in order to get an idea under consideration and tried, you need two things. One, somebody has to have the idea. Two, a person has to present it who is listened to so an idea need a sponsor and I’ve noticed that sometimes when I have an idea, if it’s really an important one, I won’t always just throw it out there. I might go talk to somebody and let it be their idea. Somebody who is like most likely to be listened to.

JACOB:  Like a virus?


SAM:  Is that a gender dynamic?

JESSICA:  I know it’s just politics, just who knows who, who listens to who. I mean, a gender can be a part of those politics. There are some people but they’re not going to listen to me or any other woman but those are rare in my personal experience.

SAM:  Because they’re all at Uber.

RYDER:  Earlier, Sam I was agreeing with Coraline but that said, but it is that way. I think the more we can recognize that as a reality and overcome this knee-jerk, yeah it’s terrible that it’s that way and I’m disgusted with the politics of it. The more I don’t want to be involved, the more effective we can be in some ways.

JESSICA:  There’s stuff we can all do to help with that which is when you hear someone’s idea and you’re like, “That might be a good idea,” or even if you don’t have no idea, there’s a good idea but you observe that it’s not being heard: amplify, echo.

CORALINE:  I get so angry if I go on a rant and I have notifications turn on and it’s like, “So and so is like this. Like 52 people like this.” I’m like, “Why didn’t 52 people fucking retweet it?” You know?


JESSICA:  I would really like to get back to the technical interview question and in particular, I’d like to hear from everybody. What are the best technical interviews you’ve had? What is a good technical interview?

SAM:  I am very biased towards pair programming so I’ll just get that out there. But many of the best technical interviews that I’ve had and I’ve had some good ones, involve pair programming with somebody else. When I was at Living Social, I interviewed with a bunch of people including [Raine Hendrix?] and we sat down and we actually paired on a bug that he had observed in production and that was really fun. In the end he’s like, “That’s a really neat solution. Let’s put that into the code.

There was another one where I was interviewing and the person that I was with sat me down and I started writing a test for the first feature and I made it pass. I went to write the second test and he reached for the keyboard and I was like, “Wait, what? You and I actually ping pong this? Great!” And I tossed it over to him and that was a wonderful surprise. For me, the best interviews are those where I get to learn a lot about the person that I’m pairing with. For me, pair programming is the best way to do it.

RYDER:  I have to agree emphatically.

JESSICA:  It’s not what can you do within an hour by yourself with no guidance.

SAM:  Right. It’s really the best way to find out, at least for me, how somebody else thinks. Now, I have to acknowledge that this process is biased against people who don’t do well in that environment and I don’t know how to address that.

JESSICA:  Well, I guess if you have a pairing environment, the best way to interview is pairing. I agree. Those are my favorite interviews too. Especially, remote pairing because then you don’t have to fly a candidate in, you can get a good idea of what it’s like to work with them without going anywhere.

RYDER:  Yeah, we have these tools. Why not make use of them?

JESSICA:  I like remote pairing, even better than pairing in person.

RYDER:  How come?

JESSICA:  You got the personal space problem figured out.

SAM:  Yeah, I love using remote pair programming tools when I’m pairing in person because we don’t have to sit together and crane our necks to see the same screen.

JESSICA:  Right, everybody has their own keyboard. Everyone is comfortable and you really do have your own screen. Sometimes, I’m watching exactly what you’re doing. I have might switch over to Chrome and looks something up for you or I might be keeping my eyes on Slack and it’s like all of the input and the back and forth, without this pressure to look like you’re staring at the same thing all the time. It’s like not having to maintain eye contact in a conversation. You can focus more.

CORALINE:  I had a really great interview experience at GitHub. There was a take home exercise which take home exercises are kind of [inaudible] because they assume a certain level of free time but this was relatively small. I think it took me an hour to complete it. GitHub does anonymous reviews of the take home assignment so you’re assigned non-identifying ID and associate it with a repo. The people who do the technical review have no idea who you are, what your name is, what your gender is, what your background is. It is strictly a technical evaluation.

Assuming you get past that level, there’s fake pairing where you have people watching you but not ever taking control of a keyboard but walking through an actual web app. If you’re applying for a web developer position, you’re like do you see any problems with performance here. The interesting thing is to tried our best to avoid bias, we have a rubric for every single question that gets asked of a candidate so we say if they talk about X, this is worth five points. If they fail to talk about X but they mentioned Y, that’s worth three points and so on so there’s no room for, “I wouldn’t have a beer with this person after work,” and kind of crap like that. It’s all very well-defined in terms of what kind of feedback you can get from them. Then best of all, in my opinion is at the end we actually ask questions about awareness of social issues in programming because that’s the reflection of what the company values are now.

I should also point out that I interviewed with eight people and six of them are women and GitHub does its best to not have a chain of white dudes that you talk to so you’re not getting eight Chads. You’re getting a cross-section of people from different parts of the company and from different backgrounds. I think that really affects the overall experience.

JESSICA:  Was it eight people in one day? I hope not.

CORALINE:  No, some of them is about half and half.

JESSICA:  Okay. Because that’s another thing that I find in a good interview is two hours max in a day. If you’re doing it remotely, you can still have more interviews just don’t put it on the same day. That’s so stressful for people.

SAM:  Yeah, and if you want to make good use of your developer’s day who’s doing the interviewing, they can do three two-hour interviews in one day but they don’t have to be with the same person.

JESSICA:  One other example of a good interview that I liked, they gave us some code to look at. It was like a little sample application. This is back at my Java days. I had a little Java app and there were deliberately some bugs in it, there were deliberately some key code. There were plenty of opportunities for you to comment on the application until the interview, once you came in, they gave you a feature and asked you to implement it. But it was the code you’d already gotten to look at and they also asked you like, “What would you change about this code if you had time?”

That’s was low pressure, getting to know the code, take as much time as you need. Then in the interview, can you talk about it? Not can you implement a ton of stuff in a short amount of time but can you step through it? Then the actual thing they may ask to implement was small enough that there was no rush. I like that one and that’s with a lot of prep on the part of the department. It was good.

SAM:  But you got to reuse it.

JESSICA:  Yeah, but actually, they stopped using that interview because the code got out of date and it was nobody’s job to update it.

SAM:  That seems like a really good way to maybe find out if somebody has the skills in diplomacy to be able to critique code without doing the throwing up your hands and saying this is crap and doing a table flip and leaving the room, right?

JESSICA:  Yeah, that’s true.

SAM:  Did anybody do that and got filtered out on that stage?

JESSICA:  I interviewed at this company with that interview. I didn’t do interviews.

RYDER:  I think it sounds like a brilliant process and it evokes some of what you were talking about too, Sam as far as like using code that is actually used like when you describe your Living Social experience. That’s critical, that’s huge. It’s so valuable and Jessica, this just occurred to me for some reason when you were describing your experience but if we could actually take it a step further and like in medical school, in certain medical programs, they’ll have actors who are playing the roles of patients and then they’ll have this number of symptoms on which you do your differential and so on. Could we have actors playing the role of a recalcitrant engineer or some terrible boss and just have a scenario where we put you in and we see how you work in that situation. We see what soft skills you leverage. We get just a little more insight not just the code review piece but what makes you throw the table and rage quit.

SAM:  I think if a company did that to me, I would leave.


CORALINE:  [inaudible] that a very prominent, large consulting company. They were like, “There’s going to be this logic test and we’re going to give you a sample test first,” and there were four or five candidates at the same time. They said, “We’re going to give this test first and feel free to collaborate,” so the sample test was maybe four or five questions and basically, it was a state machine and you had no scrap paper to work off of. A lot of trace through the state machine and perform the calculations on the numbers that were provided as inputs and just say what the output was.

There’s a lot to keep in your head at the same time and there is this guy who is like, “I don’t know why I have to do this. I’m not applying for a technical position but I guess I have to do this anyway,” and he kept asking me for help. He was like, “What did you get on step seven of problem number two?” I’m trying to keep numbers in my head which is problematic for me personally, anyway. I have an actual problem with that. He kept interrupting me and I kept losing my place and I have to go back and start over so the sample test was done. She comes back in and she’s like, “All right. Here’s the real test. You have one hour to complete as many problems as you want,” and business guy continued to ask me questions. I was like, “I don’t think we’re supposed to be collaborating anymore. He’s like, “No, I think it’s fine for us to collaborate still.” I had misgivings about that and again, these problems are even more complex so I was not able to finish more of them. I didn’t do well on that test at all and I suspected that after the interview, he was a plant to see how well I would do at interruptions and that made me so angry.

JACOB:  Like a mind game, right?

SAM:  Yeah.

JACOB:  Like are you supposed to follow the instructions and then not get in trouble for not following instructions or you’re supposed to like collaborate because that’s what a good programmer does. It’s like what’s the thing that’s going to get me the job because at the end of the day, that’s why you’re here to do.

SAM:  Where is the ethical review board on that?


RYDER:  Yeah, that does sound very stressful and sub-optimal, definitely. Coraline, I want to ask you, had the company been upfront about, “We’re going to put you in a situation and we want to see how you respond. Would that have resolve your misgivings or no?

CORALINE:  Potentially, it would have changed my interactions with the interrupter but really the nature of the test itself was stacked against me because as an example, if I asked someone for their phone number and they tell me their phone number, I will remember the first two digits if I’m lucky. The rest simply falls out of my head. I cannot process numbers in that way.

With no way to write down the interim steps and write down my interim numbers, there is no way that I could have done. Even under the best circumstances, I could not have done well in that test. As a logic test, I guess it was well-designed but for someone like me with that kind of mental block, there was no way for me to pass it. If that didn’t relate to the work I was being done, it was not a good test.

SAM:  They produced a false negative.

JACOB:  My wife does HR. She sits in every interview that her company does. She was telling me that it’s a really popular thing in interviews — you’ve probably gotten this before, I have — just some kind of theoretical to see what would a candidate do in a situation like this. She was telling me that every version of that question is just fundamentally bunk because everyone knows how to cheat that. Everyone knows how to hack that question because they answer how they know they’re supposed to. But really, what you’re really interested is dispositionally, what is that person disposed to do when they’re not under a microscope.

RYDER:  Yeah and everyone on the driver’s test puts, “I would not accelerate at a yellow light.”

SAM:  Exactly.

JACOB:  Let’s just remember that there are some limitations. I would guess, most interviewers are not psychological experimentalists. The thing they think they’re doing that’s so clever, may actually not be that valid and let’s try to be transparent about what we’re trying to get from people.

CORALINE:  But Jacob, we are scientists.


JACOB:  I have zero beakers in my office.

SAM:  My daughter has a water bottle shaped like an Erlenmeyer flask with a straw on top. It’s adorable.

CORALINE:  Did you do AB testing to determine what the best water bottle for her was?


SAM:  No, I think she got it as swag somewhere.

RYDER:  Sam, I agree with you the pair programming pieces is really important. That for me is the fundamental thing. If you’re doing it with production code, that’s even better but just aligning as closely as possible, the circumstances of the interview with the circumstances of the actual work you’ll be doing that job.

SAM:  Yeah, I’ve seen some companies espoused the idea that you should not interview at all and instead, do a one-week contract project with this person. I can see where they’re coming from with that. Of course, it also selects even more strongly for somebody who has the free time to be able to take a week off of their regular job and then come in interview with you.

RYDER:  It does. Ideally, I guess they would put you up in a hotel and they would pay. No, there’s no good way to do that.

SAM:  Yeah.

CORALINE:  If you’re unemployed, it’s a mini-vacation but if you have a job then you’re sort of stuff that came down that are like, “I have a cold and it’s going to last a week.”

SAM:  Or if you have kids or if you caring for a family member or pretty much, any of a variety of other things or you have a disability. It selects against a lot of people, which I mentioned earlier the idea of a false negative in that logic test that you described, Coraline and I want to talk at least a little bit about some of the sort of background radiation that I’ve observed around the hiring process.

Every once in a while, I run across an article about how to structure your interview process. Even in the days before [inaudible] pieces were a thing. One very common theme that I see in those is this idea that your interview process should be skewed in favor of producing false negatives because it is — according to these people — much better to reject a good person than to hire a bad one because hiring a bad person is somehow thoughts to be extremely costly. Maybe there’s an HR perspective on that. I’m not sure but it seems to me like structuring your interview process in that way means that you’re going to miss out on a lot of good candidates and it means that you’re going to miss out on a lot of diversity that would really benefit you as a company. Anyway, I just wanted to mention that as I mean that’s out there.

CORALINE:  It makes you risk averse, right?

SAM:  Totally because the risk is you fire somebody and then they sue you because they thought there was an implied contract or something.

JACOB:  You usually have more to lose from a toxic person, unless the person is great, have to gain by hiring a great person. One toxic person can take everything down.

SAM:  That’s true and I’ve seen that happen.

RYDER:  Yeah, and certainly the perception it sounds like these HR departments are working with.

SAM:  Right but say it with me, everybody: HR’s job is to protect the company.

CORALINE:  We introduce this notion of a probationary period of three months or something like that, where it’s long enough that you can feel you can safely leave your job and maybe three months is long enough to determine if you’re a toxic person and to have an escape clause for the company or it’s like, “We made some kind of mistake. You didn’t meet all the criteria for a valued employee so we’re going to try and find someone else.” Maybe that would help solve the problem. I don’t know.

RYDER:  As a new person, I would have strong questions about what is not being said about some kind of writer like that.

CORALINE:  Yeah, they have to be very explicit like these are our expectations and you have to have regular check-ins to see how you’re doing. You wouldn’t want to be surprised at the end of three weeks or three months, rather.

RYDER:  Yeah. I think if there was a writer like that, I would be extra on the lookout for strange culture in that place because if I get a whiff of like there are a company that’s like looking to axe people left and right when they make one mistake… I have a stable job now.

SAM:  Yeah, I’ve worked in one place where the lesson that I took away when they and I parted ways was that I really, really should have asked what is the median tenure of your employees because it turns out it was like two months.

RYDER:  And why is it what it is? Why do you think it is what it is?

SAM:  Right.

CORALINE:  [Singing] “To everything turn, turn, turn.”


RYDER:  Sounds like we’re saying it takes work to make the hiring process better.

SAM:  Yeah.

CORALINE:  It’s got to be somebody’s responsibility. There has to be one person responsible for making an experience as effective and positive as possible. You can’t leave it up to, “Oh, you’re a manager here. Figure out what to do.” This is an area of specialization.

JACOB:  Yeah and interviews can be — what’s the word? Not traumatizing. That’s over dramatic. But people can walk away with hurt feelings after interviews and then if they end up getting the job, they’re going to take that in with them when they start, if they start.

CORALINE:  Well, it’s been really great discussion today and Ryder and Jacob, I’m so happy that you’re able to join us today. I think the lottery turned out just perfectly and we got some really interesting conversation with you both. We want to thank everyone for listening and we will be back next week.

I have to remind you one more time that if you want to support us as a listener, go to Patreon.com/GreaterThanCode, pledge at any level, get access to our Slack community which includes our guests. Our guests stick around and you can ask them questions so if you feel like there’s something we didn’t cover in the podcast, you can get your question answered which is pretty cool. Again, thank you all. Thanks to our guest panelists and thanks to you, the listener.

This episode was brought to you by the panelists and Patrons of >Code. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode. Managed and produced by @therubyrep of DevReps, LLC.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.