Enjoy the Interview with Laurie Barth

[00:00:00] AC: Oh, my God. My mouth keeps f*cking up. I’m just not having a day.

[00:00:04] T: Make sure not to edit that part out.

[00:00:06] AR: Yeah, that’s going in.

[INTRO]

[00:00:07] ANNOUNCER: This episode is brought to you by CloudFlare Pages. For more visit enjoythevue.io/cloudflare-pages.

[EPISODE]

[00:00:27] T: Hey, everybody. Welcome to Enjoy the Vue. I'm Tessa and today on our panel we have Alex.

[00:00:34] AR: Hello.

[00:00:36] T: Ari?

[00:00:38] AC: With more confidence, hello.

[00:00:40] T: I guess, it's my name, it’s still on the script, Tessa. Hello. Our special guest for this episode is Laurie on Tech. Wait, no, her name is actually Laurie Barth. Welcome, Laurie. Laurie is a senior software engineer and you may have seen her around the internet. 

[00:00:58] LB: Hi, everyone. 

[00:01:00] AR: Did I miss anything in the intro or?

[00:01:02] LB: No, I'm laughing being introduced as Laurie on Tech because, when I go to conferences, I don't even use my last name, because most people don't know what it is.

[00:01:11] T: Yeah, you know that Laurie.

[00:01:13] LB: I just put ‘on Tech’ in parentheses, and more people know me by that than anything else. 

[00:01:19] AC: You should just be Laurie, not Boss. 

[00:01:26] LB: Ouch. I’m going to tell him you said that.

[00:01:33] T: She's also a fearsome Imposter. So, sleep with one eye open.

[00:01:37] LB: Accurate though, I haven't played in way too long.

[00:01:41] AC: She's very intimidating. 

[00:01:44] T: Today's topic is everyone's favorite way to spend their free time: interviews. Have any of you ever been interviewed before?

[00:01:53] AC: No, just kidding.

[00:01:56] AR: Like for a podcast? Because, yeah, I've been interviewed for a podcast a few times, but –

[00:02:03] T: Yes, we all know what it's like to be interviewed for our podcast. This is a fantastic topic and a great way to connect to our listeners. We hope you appreciate us as much as we appreciate you.

[00:02:14] LB: I feel like Tessa sounds like an infomercial. 

[00:02:17] AC: Wait till you hear our next ad.

[00:02:22] T: Let's talk about interviewing for jobs.

[00:02:25] LB: Ah, that interviewing? Yes. Can we like refer to that as the topic that shall not be named? Feels most appropriate.

[00:02:33] T: Well, yeah, no, I was just going to ask, because anybody ever engaged in topic that will not be named-ing.

[00:02:40] AR: I’ve topic not be named-ing before.

[00:02:43] T: The transcribers are going to love this.

[00:02:45] AR: Yeah, they are.

[00:02:48] LB: I have also participated in the topic that shall not be named.

[00:02:52] T: Any particularly remarkable ones that stand out?

[00:02:56] LB: Oh, my gosh, so many, so many. My most recent favorite is an interview that I had where I talked to a recruiter, and she was like, “Sounds great. We're going to fast track you to our final rounds. It's four conversations.” I was like, “Wow, that's the shortest interview I've heard about.” This sounds awesome.

I get to the interview, and the first conversation, I think maybe I talked to the hiring manager before the final round, but whatever. The hiring manager conversation went perfectly well. Then, I talked to someone else. It was like this weird sort of distributed systems interview. I stopped halfway through and I was like, “I'm sorry. I'm okay at this stuff. It's not really my area of expertise, or really even interest, I can talk about it. Is this part of the job that I'm interviewing for?” Because I didn't think it was. 

He goes, “Oh, what job are you interviewing for?” I'm like, “I’m sorry, what?” I was like, I told him the team. He looked it up and he's like, “Oh, I'm actually not familiar with that team.” That happened in the third conversation, and the fourth conversation, and one of them had heard of the team. It's because this company, at staff level, decided to do generic interviews and their thought process is if you're talented enough to work here, then we'll hire you for a team, just generically. I’m like, that makes sense if you are a shop of like five people, and you're all contributing to everything. This was a company of 1000s, like a company you all have heard of. 

I'm like, you haven't changed your interview practices in a long time, because your idea is, at the staff level, you'll be able to contribute across the board, but at the staff level, you're an expert in something and if you're interviewing them about everything. So, I bombed this interview, like straight up bombed this interview. I even bombed the actual hands on live coding part, because I was just so tired and really demotivated and that was the last session of the day. I just bombed that too. I told the recruiter after I'm like, “I didn't pass those interviews.” She’s like, “No, no, I'm sure you did fine.” “No, no, no, I really didn't pass those interviews.” And she sent me an email two days later. 

She was like, “Yeah we're not going to move forward, but thank you so much. You clearly have a lot of experience, I'm sure you'll do well.” I could tell she was shocked. She was like, how can this person be that good at faking that they have technical skills they have this ridiculous breadth of experience. I was like, I'm not that good at faking it. You all ask terrible questions. What were you thinking? I should have responded with that feedback. I didn't, because I was just exhausted and demotivated at that point. That's got to be a top two, maybe top three for me. I'll do some of the other terrible ones as we move forward in today's conversation.

[00:05:40] T: Yeah, I feel I remember you commenting on twitter.com that generic interviews are definitely the best way to go.

[00:05:47] LB: Definitely not sarcasm at all. 

[00:05:49] T: I do feel like that fits into a lot of what I've seen on career ladders though or just job descriptions casually during interview processes is, a lot of times, it seems the higher up you go, the more people expect you to be a full stack developer. I guess, if you were full stack instead of front end, then you would become a fuller stack developer. There's always phrases ‘you should be able to jump into any area of the code-base at any time and immediately make a big impact’. I'm like, “I don't know if that's ever going to happen.”

[00:06:22] LB: Here's the funny part. I am a full stack developer. I am literally currently writing a Java back end, and a Typescript front end, and I was a consultant for seven years in which I did everything from database design to writing a front end in Vue. I had to get my Vue reference in there. I am a full stack developer and I still – I was just so caught off guard, I was like this level of depth on load balancers doesn't really make sense. 

I know what a load balancer is, I can talk somewhat intelligently about it. It also felt like gotcha questions, because there would be, in a systems design round, they were talking about something and he was like, I would – he's like, “How would you do this?” I started going into actually doing it. He's like, “Well, the answer was AWS.” I was like, that's not an answer. That's a tool. Most of the times in interviews, you can't just say, I use dot sort as a method. Be more specific, if that's the answer you want.

[00:07:19] T: Really? Because I've heard a lot of times you can short circuit an interview, like if they're like, “Alright, here's this algorithm.” You're like, “I just use a map.” Then they'd be like, “Great, next question.”

[00:07:28] LB: They were inconsistent. Like certain questions, he was “I expected that.” I’m like but, two questions ago, you wanted me to explain something instead? I think probably the answer was, answer this quick way and then I might add follow up questions, but if that's the way you're going to run an interview, people can't guess, like people can't read your mind. You need to preface, you need to set your expectations at the beginning. Some interviews – I was talking about this with someone the other day, some interviews are saying, this is meant to be challenging, and stretch your knowledge, we don't expect you to get through it. 

For other interviews, it's this is meant to be simple, make it as simple as possible to keep working through it. Don't add edge cases or other things. We don't care about those things, but if you don't preface your interview with that, neither of those things are going to come across and people are going to make the wrong choices and do terribly as a result, because they're not meeting your expectations. As you can tell, I can rant about this for way too long.

[00:08:23] T: How about you Ari, any memorable interviews?

[00:08:26] AC: What's interesting is, I totally thought I bombed the technical, the take home for my current job, lot the point that, as soon as it was done, I made myself a drink because I was like, that went so horribly. There's no way I'm going forward with this. But as it turns out, I guess comparatively speaking, I was amazing. What I ended up doing in an effort to maybe make up for it. I did a personal retrospective on it. 

Figured out why exactly things went wrong, because it was time-box, three hours, build this basic thing with fake data that you have to make yourself. I hate that. I hate when they do that. Just give me the frigging data. But apparently, that was what sealed it for me is they loved that I did a retrospective. So, takeaway there, if you're really mess up, just say why.

[00:09:24] LB: I understand the time-box things for so many reasons, but the time box also really frustrates me, because I think we have this idea that seniors or juniors but faster, which is like wrong. I literally spent an entire day yesterday trying to figure out why the mocking library was causing a broken test. It turns out, it was the testing library, and like I spend a day doing this. I'm not any faster than anybody else. I get hung up by the same problems. I've been doing this for a decade. The idea that, in an interview, you can solve an algorithm faster is nonsensical.

[00:10:03] T: Yeah, listen. I debug my problems, one console log at a time, just like the rest of you.

[00:10:09] LB: Yes, absolutely. That's what I do. I don't know – I mean, I'm sure there are people who don't do that, but good for them. I guess. 

[00:10:17] AC: Feel like no matter what we do, and what approach we take to tech interviews, they will always be broken, and will always marginalize someone. They don't know how to fix that. If anyone has great ideas, please share them now.

[00:10:35] LB: I've written about this a bunch. I’ve developed a lot of interviews. 

[00:10:37] T: You don't say? Laurie, you? Write about stuff? Get out of here. 

[00:10:41] LB: Sometimes, I develop interviews, sometimes I interview people even. Nothing's ever going to be perfect, but we can get a lot better than where we are now, a lot, a lot better, and a huge part of that comes down to recognizing that developing interviews takes an epic amount of time. It takes an epic amount of time for a couple of different reasons. One, because you actually have to take the time and figure out who you want to hire in some explicit way and too many people don't do that. They're like, “Oh, we need another team member, let's use the wreck that we use for the last one.” 

Well, the last one was different, because the makeup of your team was different when you wrote it. So, you probably need to revisit and think about what you really need now. Then the second is they steal an interview from someone else because they don't want to write their own and that doesn't match the job that they put out the request for in the first place. Then, the person interviewing them thinks, “I'm so great at my job, and I'm an interviewer now. I should get someone who has the same skills as me, because that's what makes me good at my job,” because people are really terrible at self-reflection and recognizing what actually makes them a value add to their company, and how other things in other people might make them value adds based on the current makeup of the team. 

Do this, like one, two, three punch of people not putting in the time and effort to sit down and look at humans, because we're bad at judging humans, both ourselves and others. When you put all those things together, it just results in an absolutely terrible experience for everyone.

[00:12:11] T: It's almost you're saying, how many Legos would it take to build the life size model of Buckingham Palace would not be a good interview question, but that can't be right.

[00:12:19] LB: I mean, it would not be a good interview question, because Legos, plural is not a thing. How many Lego bricks would it take would also be a terrible interview question.

[00:12:29] T: I can't believe I just got ‘well actually-ed’ on my own show. 

[00:12:33] LB: I had too.

[00:12:34] T: How many Tetraminos?

[00:12:37] LB: No, no, no, no. Yeah, I mean, those questions don't make sense, but also asking someone to do a recursive algorithm probably doesn't make sense, unless you're working on a role that's focused on backend performance data processing. Asking someone about this keyword in JavaScript doesn't make sense if you're looking for someone who's really well versed in React, or Vue, or even Angular. This is like a dead thing at this point. We keep asking these questions, because the argument is, I want people to know how it works under the hood. I'm like, that's how it works under the hood to you, because you came up historically, like you witnessed when it was that way and you watched history evolved to where it is now. That is how you understand what's happening under the hood. 

That's not actually what's happening under the hood. Frankly, someone doesn't necessarily need to know what's underneath the abstraction in order to use the abstraction, but we have all these archaic, gatekeeping concepts of what makes a hardcore engineer and what makes someone good enough to center a button on the page and make sure the on click event fires, like, come on.

[00:13:44] T: Laurie, Laurie, Laura, you obviously can't use a framework like Vue, unless you can reinvent the computer from scratch any more than you can cook a meal, unless you own a farm and grow everything yourself.

[00:13:57] LB: I drive a car and if you wanted me to understand anything about the combustion engine, I wouldn't be able to tell you it's called the combustion engine.

[00:14:06] AC: I changed an alternator once, worst experience in my life.

[00:14:11] LB: I can change oil and windshield wiper fluid. That is the extent of my knowledge.

[00:14:16] AR: That’s better than me, I can put gas in the car.

[00:14:20] LB: Oh, I can do that too. 

[00:14:22] AR: Yeah, okay.

[00:14:22] AC: I can drive a stick shift. I'm obviously better than all y'all.

[00:14:27] AR: Yeah, clearly. 

[00:14:28] T: I can sometimes identify the cars in those like three by three grids, where they're like, click on all the tiles that have a car.

[00:14:38] LB: The next level of abstraction is can you train the AI model to recognize what a car is?

[00:14:45] AR: That's the next interview question then is that should be somebody’s next interview question is, okay, cool, please train this AI to identify cars in a picture.

[00:14:55] T: Please check here to prove you're not a robot. 

[00:14:58] LB: Exactly. I talks about the one, two, three, punch and I realized there's actually a fourth punch that I forgot to talk about. 

[00:15:03] T: Can't forget the fourth punch. 

[00:15:04] LB: Yeah, which is people's inability to judge what is important based on the signal that they're looking for. So, you’ve done an interview, you get a signal, and you come away from it, and you don't think, “Oh, that person talked really well about why they were choosing to pass a set state function to a child component, instead of changing it in the parent report," or something that, or whatever. 

That person talked really well about that. Instead, you say, “Oh, the first time they went to write the use state hook, they use curly braces instead of square brackets and it cost them like two seconds of having to retype something and clearly they don't know what they're doing.” I use this as an example, because it is a real piece of feedback that happened to me in an interview for a senior role.

[00:15:53] AC: Oh, my God. So you missed the shift key.

[00:15:55] LB: Pretty much. The feedback specifically said, “This person doesn't know how to think in React.” I was like, “Yes, because I'm a human, not a computer.”

[00:16:09] T: I mean, even computers don't know how to think in React, right? It's like transpiled and stuff.

[00:16:13] LB: So, I took a function and I put a console log, I was I just want to make sure the data that I think is here was actually here, and it was, and then I moved forward. They're like, this showed that they weren't able to think in React and like had to work through it.” I was like, “Okay.”

[00:16:29] T: That sounds like a horrible person to work with.

[00:16:33] LB: Yeah, I'm sure they are. I didn't work for the company. I wouldn't know, but it was astounding. People do that in interviews and it makes no sense. The ironic part is you're talking about that's not how it works. It's compiled, and then all of those things. I work with AST’s, and compilers, and Babel, and code mods all the time. So, literally, I know what it turns into. That's still, I don't think like a computer. 

Okay, well, the way you're asking me to think isn't actually how the computer works. It's how the framework works and the framework doesn't work that way, because it gets compiled into something else. It's where you slam them down.

[00:17:16] T: I mean, clearly, the best way to judge candidates is to ask yourself, would I get a drink with this person? Doesn't matter if you don't drink, just think about it and decide.

[00:17:26] AC: Yeah, that's how we choose politicians, right?

[00:17:29] T: Right. Then be like well, this candidate wasn't Alex. So, I'm going to say no, because apparently, Alex is very good at interviewing, he shows up, he gets the job. Alex, you want to talk about memorable interviews on your end?

[00:17:42] AR: I’ve been on several interviews, I don't interview very often, because I wait until I see something that I really want, and then I go really hard for it. My first job, I'm not going to name names of the company, but they taught me a lot. I learned a lot while I was there. I put it that way. There were a lot of red flags in the interview, but it was one of those where I was at a point where I was like, I need my foot in the door, right? Things like, hey, they wanted a test week from me. So, show up for a week, they pay you, they pay you, they paying, it wasn't like unpaid, it was paid. They assign you some tasks and you finish them. Simple enough, right? 

One thing that they assigned me was like, okay, change out this thing on this development page, so that then we can get ready to go to production. Great. Cool. I'll do that. So, here's the production link, here's the Dev link. Here's how to log into Dev. Great. I'm working, one, first red flag. This was five years ago, six years ago. We were FTPing directly into the DevServer, FTPing files into the DevServer, modifying stuff kind of changing things. I'm like, this isn't – the directions that I have here and what's happening on this DevServer aren't quite lining up. Let me go see what production is doing, because you had a production server pointing at the DevServer.

[00:19:14] AC: 99.9 percent sure, I know who this is.

[00:19:18] T: It's Alex. He's right here.

[00:19:20] AR: I know. It was very interesting. It was a very interesting week and I stayed there a year, I got hired. I stayed there a year but, oh man, like even going into it. I was like asking people like should this be like how things work? People were like, oh no. We had many conversations after that about that fact and things changed, things improved. While I was there, they started using version control, which was nice. 

[00:19:44] LB: I'm sorry, started what?

[00:19:46] AR: I have many stories about that job, they're still doing their thing. That was like the weirdest interview. I never experienced an interview like that again. 

[00:19:54] AC: I think one of the most interesting interviews I ever went through was, they were hiring for a pair of programmers and you applied as a pair. Part of I think why they wanted to go that route was they were very specifically hiring out of a boot camp, that was their target. So, I think they felt that by hiring a pair, it was going to be higher quality despite the junior level.

[00:20:23] T: Right, because you only buy a pair of boots, so it make sense.

[00:20:27] AC: Yeah, obviously. 

[00:20:28] LB: This is like the mythical man month.

[00:20:32] AC: I mean apparently like they were just really big into pair programming. They're like that was their thing. Honestly I didn't hate the interview process, but I will say, pair programming in front of someone is I don't know – somehow even more nerve wracking than just live coding in front of someone by yourself, because you're also trying to manage the nerves of the person you're pairing with, in addition to your own nerves, or at least that was my experience, because, no, my partner clearly, she – despite the fact that she was an actress in her spare time, like that was her passion, had horrible stage fright when it came to interviews.

I knew this. I'm trying to like help her calm down and guide her through it. Also, because I felt it's – we’re trying to make each other look good in that situation. So I'm like, you know this. It's this, like, I know you know this.

[00:21:36] T: What is it? It’s this thing. Great job. 

[00:21:41] AC: I mean, honestly, I felt like given that the target was boot campers, I did feel like the interview process overall, was gentle. I mean, you have to evaluate technical skills one way or the other, or at least you have to try to, I mean whether or not they do and succeeds in that. I figured, giving us – it was a it was a pretty small task and we had an hour to do it. It was basically just connecting to some GitHub API and getting some stuff back, but I felt like yeah, overall, it wasn't bad, but yeah, the whole concept of hiring is a pair was weird, but also really cool. Made it to the final round did not get the offer. 

[00:22:22] LB: Hearing you talk about getting some data from an API and getting it back makes me realize one are the problems that I saw was the job you're doing, you can be perfectly competent at. It can be the same title, and the same general ecosystem as the job you're applying for, and do entirely opposite things, because I was asked to write a fetch request in an interview after working at Gatsby, which doesn't really do that, because it's all statically generated at build time. I had to Google it. I was like, I don't know the last time I wrote a fetch call, I literally don't remember what the syntax is. 

They're like, that’s strange. Then I explained, obviously, where I worked, and what I was doing. They were like, oh, that makes more sense. It's didn't mean that I don't understand React, it just means I haven't been operating with live data for a while.

[00:23:13] AR: I have to look up how to do a fetch call every single time, not going to lie, because I used Axios for so long, and they're so close. They're so close to being exactly the same and they are not at all.

[00:23:25] AC:  I'm actually not sure I've ever written a fetch call. I've always, either done Vanilla XHR or Axios.

[00:23:34] AR: Oh, wow. Fetch has been interesting, because I liked it, but I look it up every time. Yeah.

[00:23:41] T: The syntax is very nice. 

[00:23:43] AC: Yeah. They did a good job with it, for sure. 

[00:23:46] T: I think this idea of like you have to evaluate their technical skills is interesting, because on the one hand, yeah, maybe you do. On the other hand, I feel like, theoretically, if you can pick up stuff, and the company is there to support you, between the two, anybody should be able to get somewhere, but I almost feel like there's a disproportional amount of offloading that responsibility of having support and documentation and onboarding and like some kind of system for somebody to work within and be supported by and continue to support is put on to the incoming developer.

[00:24:23] LB: That's definitely true. I think the need to evaluate their technical skills, the team, the company, the role, and the level, all of those things go into how much you should need to do that. If you're hiring a junior developer, don't you just want someone who can take feedback and communicate when they're stuck, and knows that the variable name goes on the left side of the equal sign? Isn't that really what you want? Beyond that, you're expecting them to learn pretty much everything. 

If you're looking for an intermediate developer, you're looking for someone has some comfort level with the language that you're talking about. Again, can like figure stuff out. I think the problem is, there's a type of developer where you really, really care about their deep technical skill set and that's when you want them to augment expertise in a specific area that your team doesn't have. It's not just like, oh, can you figure out how to write code in JavaScript, it's can you tell us that we should be using Cypress versus something else? Can you tell us that when there's a problem with Webpack, it's because of its interactivity with the way we're using a new Babel plugin, that ecosystem stuff. 

There is a type of engineer that you are hiring for, that you need them to fill that role on your team, but I think we assume all of our roles are like that. Therefore, everyone needs to have the expertise, ignoring the rest of the team. It's like no, you're looking for the person who augments your team. If you already have that person, if you already have the domain expert, why can't you just hire someone who can figure it out and match the patterns and keep moving forward and learn on the job? They should be perfectly sufficient for the opening that you have. If you don't have anyone to lead the ship, maybe that's a different conversation.

[00:26:18] T: Laurie, we have to hire the best and the brightest, so that everybody feels lucky to be working with people smarter than them. I am so tired of hearing both of these phrases. You don't need the best and the brightest. Mediocre is fine, like you're building an e-commerce site, calm down.

 [00:26:36] AR: Let's be honest here, let's be honest here. They say that they want the best and the brightest and then they end up hiring a mediocre white guy. So, like –

[00:26:43] LB: Wasn’t going to spit, wasn’t going to stay. So, here's the thing, I feel very strongly about the second thing you mentioned, which is I want to work with people who are smarter than I am, but here's the trip. Everyone is smarter than I am. It depends what the measuring stick is and what category we're talking about, right? Every single person I work with, what it should really be is, I want to work with people who I can learn something from. If there's someone you're working with that you can't learn anything from, sorry, but like, this is just not how this works. 

You're telling me the most junior developer on my team who can't teach me anything about code and that's still probably not true. They probably can, but let's just say they've literally never touched anything, they don't know anything about a computer, but we hired them anyway. Can they teach me how to be a better teacher? Yes. Can they teach me how to communicate better? Yes. Can they teach me how to look at problems and get out of my own head from being too close to the problem, to see it fresh for the first time and maybe see things I wouldn't have seen otherwise? Yes. Can they probably teach me how to have more tenacity? Yes.

They can teach me five million things. The person who's my exact clone can teach me a lot about how impossibly difficult I am to work with and how I should change. So right like everyone can teach you something.

[00:28:03] AC: My first job, they actually really did not evaluate my technical skills. I mean, basically, he wrote like seven console log statements on a whiteboard and asked me like what they would log to, basically, it was like does the number one double equal string, number one, what does that evaluate to? I was like obviously true, but I avoid using double equals, in general, is it okay, that's all I need to know, we're done. Okay. Then, I stayed, and I hated my life.

[00:28:40] T: I have met entry level developers that wouldn't necessarily be able to answer that question because, for example, the school I went to specialize in JavaScript, but some split time between JavaScript and Ruby. So, there's like even trivia like that, that they might not get just because they haven't had that depth. 

[00:28:56] LB: I also hate trivia. I hate trivia. 

[00:28:59] T: I'll take trivia over like a five day take home bill anytime.

[00:29:03] LB: I mean, agreed but they're both terrible. So, can it not be either or and can it be neither? This is the thing that I find really frustrating is people talk a lot about “we can solve all this with a take home.” I'm like, “No, you can't.” Because there are so many people who can't afford to spend the time to take your take home and if they can, they're going to do it in exactly the amount of time you told them to spend and someone else who has nothing but time is going to do it over the course of a week and hand it in and tell you it took them four hours. That's just the way it goes, right. 

It's not that it's a bad thing. I personally think we should offer both to people we should say do you want to do one hour synchronous? Or do you want to do a three hour take home? It's up to you. If there's someone who said, “My anxiety is really high, but I also don't have the time to do a take home.” You figure out a solution but at least then you're trying to give people – the goal of an interview, in my mind, should be for people to show you what they know instead of what they don't know. If you're giving people options, you are giving them the opportunity to present themselves in their absolute like the best skills they have in their best light. 

Actually, when I interviewed for Marcy Sutton at Gatsby, in various parts of the interview, she had a pick one out of three. It's like you can write about this, you can build this, or you can present on this thing. I got to choose which, what's so wrong with that? Everyone's well, I wouldn't be standardized. I'm like, it's not standardized anyway, because giving the same thing to a person with test anxiety and someone who doesn't have it, or giving a take home to someone with free time versus someone who doesn't have it. You're already biased in one direction. So let them choose the way that's least biased towards them.

[00:30:51] T: Yeah, this idea of everybody has to do the same is really misguided at best.

[SPONSOR MESSAGE] 

[00:31:00] ANNOUNCER 1: Previously, on Cloudflare for the Dramatic. 

[00:31:04] ANNOUNCER 2: Hey, I need a website for my rain forest themed bookstore, but I don't have a big budget for ongoing server fees. Is that, like, something you can do? 

[00:31:14] ANNOUNCER 1: Now, Cloudflare for the Dramatic.

[00:31:18] AR: Did you see the requirements list for this site?

[00:31:22] AC: I know. It's a 1,000 meters long.

[00:31:26] AR: They need us to use a JavaScript framework.

[00:31:32] T: Cool. Cloudflare Pages supports gems –

[00:31:35] AC: And they need something called Git Integration.

[00:31:37] T: Yeah. Cloudflare Pages allows you to publish right from your GitHub repo –

[00:31:41] AR: And on top of all of that, we expect this beast of a website to be performant?

[00:31:51] T: Like I've been trying to say, Cloudflare Pages supports all that and allows you to collaborate with others using advanced site previews with unlimited admin seats. So, you can include the whole team. Plus, it's super performant, thanks to their vast edge network. 

To learn more visit enjoythevue.io/cloudflare-pages.

[00:32:23] AC: Oh, no. That was the client. 

[00:32:26] AR: What?

[00:32:27] AC: They said, the site needs to call it top secret secure bookstore API.

[00:32:35] ANNOUNCER 1: Oh, no. What will happen now? Will the team be able to figure this out? Will they get that jam stack website up on running? Will they be able to make a site that works smoothly across the globe? Find out next time on Cloudflare for the Dramatic.

[00:32:51] T: Guess I'll add this to the next sprint.

[EPISODE CONTINUED]

[00:32:55] AC: I was just going to say, I will say that there's really, at the end of the day, one major requirement to work at my company. That is, you have to care about Health Care, like beyond that, pretty forgiving, but you have to give a crap.

[00:33:11] T: One interview, I bombed relatively recently, I got to choose. I personally don't really like take homes just in general, but also, especially if you don't know the company, which wasn't necessarily the case here. It's so easy for them to give out the take home. It doesn't cost them anything. So, there's not necessarily any engagement or commitment on their ends to give you something in return for you giving them your time, because it's not a one way street where they just need us. I mean, we need them, but they don't need us. I was like, “Alright, I'm going to do a live coding session.” So, I did, I got to the final rounds. I think in general, I'm pretty decent at telling how an interview was going. 

Like my first job, I was like pretty sure I got the job. One of the most de-energizing interview processes I had was where I could tell like, we did the live coding session, passed that, went to the final round and then, the final round, there's a section where they're we're going to talk about your take home, so be prepared to share your code. I was like, I didn't have take home, what's going to happen here? They're like just bring in an interview with you just in case, they'll probably ask you some Vue stuff in a code sandbox, they didn't use Vue, they used React.

They were like, you’re going to have to have all the Vue knowledge. I was like, “Okay.” Show up to the interview. If live coding like a full UI, some tie – like imagine a recipe page with tons of recipes and they're like you have 40 minutes to do this or something. It was just like interview to interview the interview, back to back to back, there was a 30 minute break in the middle, which is not enough time to eat lunch. I went back to the interview, still chewing lunch. There was a problem with the code sandbox where it wasn't syncing, on their end they couldn't see it. So they asked me to share it over zoom. I don't know what the problem was there, but that resulted in it not showing my changes. 

I kept on thinking that the code that I was writing was buggy, and it wasn't reflecting in the UI. So I would change it, and change it, and change it, and refresh manually every now and then. It just was not working. So, they were like, you were great everywhere else, but you didn't pass this live UI coding thing that you didn't know you were supposed to do. I was really annoyed, because, one, I was really anxious. I never had to live code a UI before. It's all been JavaScript puzzles. 

Also, two, I think, the biggest thing for me, because I've had interviews for example, where people have yelled at me in the interview, and like my friend at the company would be like, that's terrible. I'm like, yeah, that didn't really affect me so much as that that they were yelling at me for not knowing Backbone and you had specifically told me, it was okay that I didn't know Backbone, because I'll learn on the job. I was getting harangue for not knowing this thing. I don't know if I have a higher tolerance for some things. 

I think when you don't know what to expect from an interview, or you're told to expect one thing, for example, you're just going to have a framework agnostic design systems interview, and then turns out you have like a week long, and they expect you to take a week, take home challenge where you – I don't know, rebuild Spotify or something. Or they tell you, “Yeah, you're just going to have a chat.” Then they're like, here's Fibonacci and for some reason, for the life of you, even though you used to be able to deal with memorization in your sleep, you just cannot even remember how Fibonacci works, or what the sequence is, just like when they don't tell you what to expect or they tell you the wrong thing and you prep for the wrong thing.

I had one where they were like, yeah you're going to have to do React-stuff. I don't know, React anymore. I spent all this time studying up on React, I get there. It's an algorithms question. I get too deep into it, because it had to do with, I don't know if our listeners know this. I've done a little bit of research on the event loop. I got really deep into it. I nearly knew what the problem was, but then, could not, for the life of me, figure out how to solve it, because my mind was in a completely different realm. I think that can be really frustrating from the interviewee side.

[00:36:41] LB: No, I completely agree with everything you said. I think that was awesome. I think one of the challenges is that, the people who are communicating with the candidates, I mean, depending on the size of the company, but the person who's communicating with the candidate is rarely the person doing the interview. It's not the hiring manager, it’s some recruiter. So, the recruiter, as soon as they get the feedback that the candidate is moving on, they're like, “Okay, let's schedule your next round.” 

The candidate comes back and says, “Okay, what should I expect?” They tell them what to expect and it may not even be that the next round has been officially decided yet. All this information is out of sync. I think I understand the challenge actually, on both sides of that coin, it's you want to be able to provide the information so that they can prep, but at the same time you might be flying by the seat of your pants a little bit and finishing up stuff based on the candidates you have and what you still need to see from them, instead of having this – it's actually better than having this, this is what they're definitely going to do in the next round. 

Maybe you're adapting to the scenario, that is a good thing, but it means you can't provide the information in a timely manner. So, people get misinformation, like no information is better than bad information, but no information is really frustrating. I can understand situations where you're told the wrong thing, that's egregious, right? I can understand being told “we're going to go over your take home” and then it turns out you're not really you're just building you're entering slightly different questions. 

I don't understand being told you're working on Reactants and algorithms question. I really don't understand and have seen before, where they are like “you don't need this skill" and then the interview is all focused on that skill. I have seen that way too many times. That is where you didn't decide what you actually were looking for. You didn't match the rec to the job interview at all. That to me is just not acceptable.

[00:38:26] T: That live UI one, I found out when the interview was at 8pm the night before, it was a morning interview. 

[00:38:32] LB: Why did you go? I would have said, “No, I'm sorry, that's not acceptable.” I mean, I get it, that's a privileged position to take. Right now, in this moment in time, unless you are an entry level candidate, the candidates have all the power. There's such a shortage of engineers. I would like to see people taking that power back a little bit and being like, “No, you can't treat me crap. You can't grill me for two hours without a break, and then not give me any opportunity to ask questions. Maybe I don't want to work for you now.” 

There's so many ways in which I think companies take advantage of the idea that every candidate is just jumping to work for them and, for some companies, that's true, right? For some companies, they're going to have a never ending supply of people who want to work for them. But for other companies, they're getting a little big for their britches. Let’s knock them down a peg or two.

[00:39:27] T: Yeah, I mean, in that specific case, it was very clear to me that the company had decided to scale massively and had not yet given more support to the recruiting team. I could have pushed back and asked to change an interview, but I was like it's probably not a big deal. I felt bad for them. I do think it's interesting that you bring that up, because I think one of the biggest problems with interviewing is that a lot of companies don't care about the interview process. They don't think it's important, right? They just see us as a products or resources to be brought in for their service, and not a symbiotic relationship.

[00:40:02] AC: I recently had a lot of involvement in my company's current interview process. Actually, interestingly both for an open engineering role and for a marketing role, but actually, I will say being on the marketing interview panel was really interesting, because I got to just ask the ‘douchebag alert’ questions.

[00:40:25] T: What are those? Can we add a list to the show notes? So people know. 

[00:40:28] AC: My favorite one and this one was truly a make or break for every single candidate was, “Can you tell me about a time where you promoted diversity and inclusion in your workplace?” That, I mean, that is one that will throw people off. They don't have to answer perfectly, but how they answer will tell you so much about them. Highly recommend asking that.

[00:40:50] T: A question I have is would you mostly ask that to white candidates or will you also ask that to like, say people of color, because I don't know if all of them – I know that there's a lot of people that feel like it should not be their duty to promote diversity and inclusion. I'm curious about that. I don't mean to take away from your question. It's just, yeah.

[00:41:10] AC: If I – here's the thing, yeah. If that is their answer to me, that is acceptable, like there's no right answer.

[00:41:19] LB: I feel like the great answer for pocket of sight is to just be like, I exist in an industry that doesn't want me here. That is promoting diversity inclusion. Fair, valid.

[00:41:31] AC: I think it is important to know that there's not a right answer to that question, but that question is really good for feeling people out, like where their priorities are.

[00:41:40] LB: I was talking the other day about interviewing engineers specifically and making sure that you have women involved in the interview panel, somewhere along the way and someone was saying, “Well, our HR representative is female, and one of the managers is female.” I was like, that's good, like don't get me wrong, that there are women involved in the panel. I actually don't think that men realize that a man can – I mean, anyone but we know, it's mostly going to be men, right? 

A man can interview with a woman, period, perfectly fine if he thinks she is in a role that he expects her to be in, but the minute you're in a technical interview with a female engineer, and one of the questions – it happens all the time, in a technical interview, someone says, “Oh, that was a really interesting choice. Why did you make that choice?” To a dude, they're like, “Oh, well, I decided to dah, dah, dah, dah,” and to a woman, they're like, “Because it was the right choice. How do you not see that?”

The interaction right there tells you everything you need to know, because they can't handle the fact that a woman has questioned them on a technical decision. They can't respect her technical expertise in the first place, and not having that anywhere in the panel is problem. Like, it's just problem.

[00:43:00] AC:  You're assuming that he's even going to address the answer to the person who asked it, if it's a woman.

[00:43:07] LB: Also true, been there, been there, been there. My favorite is when there's two people – I was the lead interviewer and I had a younger male colleague shadowing me, and he was doing a great job. I was asking all the questions, and my colleague was just standing there, sitting there taking notes, this was all over Zoom, right? The candidate addressed every answer to the younger man, every single one. We finish and I asked my colleague, I said, “Would you hire this person?” He said, “No, because he was a condescending douchebag.” I was like, “Bravo. Good job. I appreciate that you saw this.”

[00:43:46] T: To be fair, Laurie, have you tried just being a man? I feel the answer is pretty simple. 

[00:43:52] LB: It really doesn't seem that appealing. To be honest, just doesn't seem a fun time. We get a better outfits, the whole like dresses. I mean, that's being very gender normy, but I'm just saying. Society expects us to have cooler clothing.

[00:44:06] T: I just want to point out that Alex has been a very quiet before weighing in with my old thoughts and not giving him a break to start talking. I think that gender diversity in an interviewing panel is really important. I remember one time when I raised the concern about the lack of gender diversity and representation on the engineering side, a suggestion was made that like, that's something that every candidate comes through and all the insight or something a lunch with a candidate could take care of. 

I was like, “No.” Because there's lots of – even friends that I would be happy to eat lunch with, but would never want to code with. The context begets different behavior.

[00:44:40] LB: I think there's a major problem because you want to have, you want to have a woman on the interview panel, if they're going to be interacting with women. If your company is basically all dudes, and they're only going to interact with dudes, don't waste a woman's time. The problem is when you don't have enough people to fill those for all the different roles you're hiring for, you end up having your female engineers spend a lot of time in interviews when they would rather be doing their job that their male colleagues don't have to do. It's like, if you don't bake this stuff in from the start, it gets really imbalanced and really messy really quickly.

[00:45:13] AC: I'm just thinking about the last company I worked for, and how, in their eight year history. I am the only woman who was ever an engineer there. I was not invited into the interview process for someone who was going to be working with me.

[00:45:30] T: I mean, all right, just you should have lunch with them. I think that's on you.

[00:45:33] AC: I was on vacation. I mean, I was on staycation. I would have happily come in for that, but nobody even told me that they were interviewing. That gave him an offer without even letting me see his resume.

[00:45:49] T: Especially with smaller teams, I feel like that's hard to understand, when everybody doesn't get to meet the candidate.

[00:45:54] LB: I don't understand situations where team members don't get to meet or at least be a part of the conversation about a new candidate. I also don't understand situations where, as a candidate, you do not get to meet your hiring manager or other team members and you get just people throughout the company, because I've seen that happen a lot. I'm like, no, I'm not accepting an offer if I don't know who I'm working with, like why would I do that? That makes zero sense. My company that wanted to hire me without meeting my hiring manager was wild. That was actually wild.

[00:46:25] AC: That is crazy. One interesting thing that we did in our recent round of hiring for director of marketing, we actually recorded the panel interview portion of it, so that all of the other employees could view it if they wanted to, and weigh in. Honestly, that worked out really well. 

[00:46:44] T: So they could Enjoy the ‘View, that’s what you're saying?

[00:46:48] AC: Obviously, you don't want literally everybody in the interview, because like that's overwhelming and a waste of a lot of people's time in that moment, but giving people at least the opportunity to be involved if they want to and give feedback, I thought, was really nice. Actually everybody was a big fan of that.

[00:47:08] T: Yeah, I was just in a panel where it was like nine people interviewing this one person, and I felt so bad. I think on the interviewer end, for me, one of the most challenging things is when you have a candidate that just won't talk to you. No, I just can't talk and you're like, “Well, what do you think the problem is?” They're just sitting there and you're like, “Well, what would you normally do if you were stuck?” and they're just sitting there. From the interviewee side, one thing that I learned that I thought was really useful was this acronym REACTO, which I thought was a real, like just known across the industry thing, apparently it's not. 

But it stands for repeat, example, approach, code, test, optimize. So basically, the idea is, this is mostly for white-boarding questions. The interviewer asked you a question. You repeat the question back to them to make sure that you understood the question correctly. Then you give a few examples of the input and with the output would be to once again confirm that you understood the question. Then you talk about how you might approach solving the problem. 

Then you actually write out the code. Then the test part is where you take those example inputs, and then walk them through your code to make sure that it works and you get the expected output. Then the optimize if you have time is just, well like I did it this way, because we have a limited amount of time, but if I had more time, here's what I might change or here's what else I might do or I actually know how to do with this other way. but brute force is what makes sense right now. 

Personally, I find it really helpful, especially let's say if I'm not going to lie, I actually enjoy interviews. I like talking to people, and learning about things, but like if you're in a high stress interview or something, I think that's really nice to have that pattern to fall back on to make sure that the interviewer is talking to you a person and not like a bale of hay.

[00:48:44] LB: I agree. It's really hard. Interviews, pretty much no matter what you do, will always somewhat cater to people who are extroverted and outgoing and talkative. The only way I challenge that is I think people who can't communicate about their code at all are probably not great engineers, but I reserve the caveat that there are neurodivergent people who are really great at their job and they find ways to make it work for them and interviewing it finding an interview that they can do well at if part of their neurodivergence is not verbal communication is really challenging.

[00:49:23] T: I think also, on the working with people, and it's an explanation, but not an excuse, right? Well, I feel it's too depressing to wrap up here. Do we want to talk about any good interview experiences that we've had.

[00:49:38] LB: I can talk about portions of interview experiences that I think are really positive. I would like to see other people do. Actually the thing that Netflix did that I really liked was, I had a touch-point with my potential hiring manager pretty much all the way through. I had an initial interview with them, but then after each set of interviews, we would have a 15 minute segue or so. They would say, “Hey, here are some questions that have come up on our side about whether or not you'd be happy here.” Like, how do you feel about these things that we're going to be asking of you? How do you feel about the role? Are you still interested in us? Very clear, both sides-isms to it. 

There's a word for that there's just not coming to me right now, but it was a very even playing field of they're like, hey, here are some things that I wanted you to give an opportunity to clear up for us and here are some things that were a little bit worried about not meeting your needs on. How do you feel about this a compromise? Or are you just not interested in this? So, throughout, I got to know my hiring manager really well. For a lot of interview processes, I felt I ended it with a ton of questions, because I'd not really been given the time to – I was trying to just get from round to round, to round, to round. 

I hadn't been given the opportunity to really dig into stuff, which is somewhat on me, but also there wasn't a lot of time provided. At Netflix, I felt like, by the end, I knew what I was getting into. I knew what I was signing up for. Three months in, I can say, I haven't really seen any surprises. They were very forthcoming and they were very honest. I think that's the sign of a good interview, that I knew the pros and cons. I wasn't lied to basically, like I knew what I was agreeing to.

[00:51:18] AR: One tip that I know, I've picked up, I think from Cassidy, but Cassidy Williams has mentioned before that when you go into an interview, you ask the same question to everybody. Always, when they go, do you have any questions? You always ask the exact same question to everybody. The one that she usually does is, what is the focus of your company? Is it the product? Is it the people? Is it like the product, the customers, or the employees? Where's the focus of the company?

As long as everybody consistently says the same thing, then there are no big indicators there, but like when, with that question, in particular it's when everybody says something completely different. You're now like, okay, that's problematic. But that's been, I know that that's been exceptionally helpful advice for me and has made some interviews go real interesting recently.

[00:52:13] AC: Another question I've heard to ask in that same fashion is, how do know what you're doing each day? Yeah. 

[00:52:20] AR: That is a good one.

[00:52:22] AC: Because a Manager will be like, “Oh, well we do this, this and this.” Because you know they're lying.” Then just be like, “Honestly, we don't.”

[00:52:29] LB: Corey Quinn says, the question that you should ask everyone is, how do I expense a book for learning? And just see how convoluted their processes and how consistent it is, like it's fascinating.

[00:52:42] T: Yeah, a lot of people might not even know, it sounds the idea with asking everybody the same question is to gauge the consistency and make sure that communication is flowing and stuff. I think it can be hard, if you're in the type of interview where they’re like, “We'll save a few minutes at the end for questions.” Then, you get to the end and it's like one minute.

[00:53:01] AC: I would say that that's not a company you should work for, because they don't care about you.

[00:53:06] T: That rules out most companies. That the things that stood out to me the most from interviewers as an interviewee, the last time I was interviewing was two places they interviewed at they set aside half of the interview time for questions, which I was really surprised by glad I was prepared, because I don't know if you know, I always have a ton of questions. I thought it was nice that they saved half the time. Also one of those companies, a lot of a lot of times companies will be like, “Oh, you brought really good questions.” It's a chance for you to impress the interviewer. 

But rarely is it used the other way around, cause there are questions that is there a chance to impress you. I've talked about this before, but one of the companies, he asked me a lot of questions about, are you sure you would like to hear – like Laurie was saying, I don't think it was show us how passionate you are, but really just making sure that I would enjoy and be a good fit. They also asked me, like how do I maintain work life balance, and the way that they asked it and that they asked me show that they really valued it, which I really appreciated and thought was very useful information.

[00:54:03] AR: I also just enjoy turning questions that interviewers have asked me back around on the interviewer. That's always it's a classic. It's just so much fun. So where do you see yourself in the next five years? Uh, uh, I – wait. I don't know. Yeah, that's really great. That's always a good one.

[00:54:22] LB: Do you want a fun version of that one?

[00:54:24] AR: Yes. I do want a good version of that one.

[00:54:26] LB: I asked people, is there anything I haven't asked that you think I should have? Most people think of that and they're like, “Oh, you should have asked about our snack perks or you should have asked about this.” But there are some people, let me tell you, that you can tell as soon as they get this question, their gears go in their head, and you realize all of a sudden that they're on their way out, and they are being honest. Or in that moment they're like, what I wish you knew is something really negative and it makes them think about their job and like it's exactly where their brain is, because they're scrambling and they don't expect the question.

[00:55:03] T: I feel like so far, all of my responses to that question have been like, “No, I think your questions covered just about everything, but if you have more questions, feel free to reach out.” 

[00:55:14] AC: That is totally hell. I’m just like, “Nope. I think we're good.” 

[00:55:21] T: Would be nice, though, because I feel some of the questions I asked are hard to answer on the spot like, “Can you name an example when you did time that when you did this or that?” So it'd be nice if both ways, like we had more places send questions in advance, which I don't think is necessarily “cheating.” It just lets you have a more thoughtful and prepared answer.

[00:55:42] LB: The other way to phrase it is, “Is there anything that you want to tell me?” Just really throw it out there, but that's a little less sneaky than the –

[00:55:52] T: Yeah, just be like, “Well, my last question is, what's the hot goss?”

[00:55:57] LB: What's the tea?

[00:55:59] AC: I’m always sure to ask what people's least favorite thing is about working somewhere?

[00:56:04] AR: Oh, that's a good one.

[00:56:06] LB: That's when they start calculating the positive flaw answer. 

[00:56:10] AR: Yeah.

[00:56:11] T: Well, you asked him the positive first, to get out of the way. 

[00:56:14] AC: You can always tell when someone's giving you a BS answer to that. That alone tells you a lot.

[00:56:20] T: On that note, Laurie, where can people find you on the internet?

[00:56:26] LB: I'm @laurieontech on Twitter. I'm laurieontech.com. I'm lots of things are linked on my website. I think I'm laurieontech on Dev? I don't know, but all my blogging is also on my site. So, yeah, I'm pretty much Laurie on tech everywhere or Laurie Barth, but yeah, mostly Twitter and my site.

[00:56:46] T: Now it's time to move on to this week's picks. Ari, would you like to go first?

[00:56:52] AC: I would love to go first. So this week, I'm going to pick something that I would have never discovered were it not for my amazing co-hosts here on Enjoy the Vue, who when I got my current job, they sent me gifts to congratulate me, and one of them included this facial serum called Heal + Glow Facial Serum. I live in a dry climate and so dry skin is a big problem, especially on my face, because I also when I'm frustrated have a tendency to do the whole hands on my face thing and apparently, that just stops the moisture out as I flirt.

Keeping my face nice and glowy with dewy moisture is a struggle, but the Heal + Glow Facial Serum definitely helps and it is a small business. So, definitely give it a try, if you have dry skin problems, or even if you don't, I technically have combination skin. Also it does not cause you to break out, because I'm going to overshare a little bit but yes, I struggle with acne and it has not caused any problems for me. 

[00:57:59] T: Sounds like you have some great co-hosts and it also – 

[00:58:03] AC: I do.

[00:58:05] T: Helps explain your dry sense of humor. With that, Alex what are your picks for this week?

[00:58:15] AR:  This week, I'm picking a board game, my local gaming store, Infinite Realities, recently had a copy of it in and we happened to be just there right at the right time to be able to pick up this copy, because they sell off the shelves like nobody's business. They are super popular. So, the game is called, Wingspan. It is the most British game ever.

[00:58:39] T: Wait, I'm sorry. You can't talk about a British game and not tell us in British English.

[00:58:43] AR: Oh no, I can. You're collecting birds, because you are bird watching. You have like this palette of birds in front of you and like you collect birds over time and you have to feed them to get them and then they lay eggs and then you use eggs to get more birds and like, just thing after thing, like it's just an –

[00:59:01] T: They are hoarding birds. 

[00:59:03] AR: You’re hoarding birds but the only way that you can interact with other people really is you can kind of mess them up by maybe taking the food resource that they want, or taking one of the face up birds that they want and that's it. That's like the only interaction that you have with other people. There's no like so – it's like this weird engine building. It's so relaxing and so chill.

[00:59:27] T: Hungry, Hungry Hippos but with birds.

[00:59:29] AR: But like less anxiety inducing than, Hungry, Hungry hippos, right? You have Hungry, hungry hippos and everybody's like, ah!

[00:59:38] T: Not them releasing the anxiety. They're just breathing it out.

[00:59:42] AR: No and then like this you like put on some bird sounds in the background and outdoorsy bird sounds. Then you're just playing with the news and then you’re just like, “Oh, boy. I just got I just got a brown Thrasher. This is really fantastic.” So like, yeah, it's a really great relaxing, chill game, I highly recommend it.

[01:00:04] T: You heard it here first kids, don't go outside and enjoy nature and bird-watch, play a bird cardboard game at home.

[01:00:10] AR: There are fewer mosquitoes that way. Yes, and bees.

[01:00:14] T: Alright, so Laurie, what are your picks for this week?

[01:00:18] LB: I'm five, normally, with all of my Lego. But today I'm going to be 12, I think. I've started playing Fortnight, because it's available on Switch and a bunch of my friends play it. It's really satisfying to run around a map and hide and shoot at things and – I'm not very good at it, but what I didn't know is that I kept winning and apparently, for like the first 10 rounds, they give you all bots and make it really, really easy so that you can learn the game mechanics and feel like you're doing well. That was an upsetting realization, but the first 10 games are super fun, because you feel like you're amazing. 

The other thing I was going to pick is always Lego, but specifically, I have the Diagon Alley Set behind me that I have not yet built. I'm always on the Lego train. I just finished building the bonsai tree. Diagon Alley is next. I'm running out of room. So, if people want to pay for an additional room in my house for more Lego so that they can see more builds, they can feel free to do that.

[01:01:15] T: Have you thought about building the addition out of Lego? I mean, I feel this is a self-solving problem.

[01:01:20] LB: I don't think Lego would really do super well with that whole weatherization thing. Probably not be up to code either. I'm pretty sure the county would be mad about that, but details. 

[01:01:33] T: I mean, you know how to code. I think it should work out. All right, so I guess it's time for my pick, which I put down before we knew what we were talking about today. It's the book called, How Not to Be Wrong, by mathematician Jordan Ellenberg. I think my e-Book store recommended this to me a while ago, and I was like, yeah, not being wrong sounds pretty fun. I added to my wish list, and then I never read it. I started reading it now, which is ironic because I was recently reminded that, sometimes it really does suck to be right, but yeah, it talks about math and statistics and different kinds of fallacies that we might make when analyzing a situation. I’m only a chapter in, but it's been interesting, and not too dry. You'll learn a bit about what's greater or not so great about math education, the stuff of kids these days.

That's all for this week's episode. If you aren't following us on Twitter, what are you doing? Head on over and hit that follow button. I don't think there's a bell, but if there is, feel free to smash that bell icon and do be sure to subscribe to the show if you haven't already on, as Alex loves to say, your podcatcher of choice. If you have the time, please leave us a review. We'd love to hear what you think. 

Finally, remember to tell at least one friend what you enjoyed about this week's episode or tell us on Twitter @gloomylumi, what your favorite or least favorite interview experience was. Thanks for listening and until next time, let's say it again. Enjoy the Interview.

[END]