Your Interview Process is a Lie | Chaos Lever

[00:00:00.09]
Chris: I have absolutely nothing to say to you.

[00:00:03.17]
Ned: So it's a Friday.

[00:00:06.19]
Chris: A day that ends in Y. It is a day that ends. It's going to be a John Kael type of episode. Just 44 minutes of complete silence.

[00:00:13.29]
Ned: You know that the day that ends in Y joke doesn't work for most other languages because they don't have that weird habit that we do of naming all of our days of the week with day at the end. It seems redundant.

[00:00:24.03]
Chris: I imagine we thought we were very clever when we did that.

[00:00:28.19]
Ned: You make it sound like English was planned in any way, shape, or form. Hello, Ledget Human, and welcome to the Chaos Lever podcast. My name is Ned, and I'm definitely not a robot. I'm a real human person who speaks English to a moderate degree of fluency and sometimes writes things in code. With me is Chris, who also encodes things. Hi, Chris.

[00:00:57.29]
Chris: But I speak English excellent good much. Well, yes.

[00:01:01.22]
Ned: Well, according to ChatGPT, you certainly do.

[00:01:04.17]
Chris: Hi, seven.

[00:01:06.19]
Ned: Joining us today, we have a guest, Colin Lacy. He's a senior software engineer at Cisco, an avid generalist, and a recovering former architect. Man, I want to dig into that. He's been building software since WordPress was cool. Spoiler, it was never cool. And in a previous life, he was a food photographer working in restaurant marketing. Hey, Colin.

[00:01:31.19]
Colin: That is all true. Hello.

[00:01:34.12]
Ned: Oh, this wasn't like a two truths and a lie scenario?

[00:01:36.24]
Colin: No, that's all true. That's my background. That's my hidden secret, the food photography.

[00:01:41.26]
Chris: No one knows that. Yeah, and that's where we're going to completely hijack this episode. And we're going to discuss the best macro lenses on the market and why they're always the Nikon 150. You can go first.

[00:01:51.22]
Colin: I actually was a huge Nikon fan, so I'm right there with you.

[00:01:58.08]
Ned: Should I just leave and let you do your thing? I understand one lens, and that's it.

[00:02:06.17]
Colin: Is it the one on the iPhone?

[00:02:08.06]
Ned: It's the one on my pixel, but yes, basically. Wow, food photography. So the rumor I was heard is basically all the food you see in photography is not the actual food. It is primed and replaced with things that are not actual food, like using Elmer's glue for milk. Is that true? Is that really how it's I'm pretty sure any NDA that I was implied to have signed when I worked for him is over now.

[00:02:36.29]
Colin: I worked for Emile Lagasse. That was who I shot food for our interview. Oh, wow. Oh, wow. Legend has it. This is what they told me in the office. Well, first of all, I had to shoot real food, and then I ate all the food that I shot. That sounds amazing. The fact that I'm still alive proves it was edible, it was not poison, there was probably no glue. Legend has it. When Emmeral shot his first cookbook, he was unaware that people use paint and glue and hairspray to make the food look a certain way. He cooked up the food, plated it, put a lot of work into decorating it for the photographer, and the photographer whips out the paint, whips out the hairspray, and he had an anxiety attack. He said, You're ruining my food. What is wrong with you? I put a lot of work into that. And producer of the was like, No, this is how we do it. This is how it's going to be. And he got into a legit argument. That's not food. At this point, we're just lying. So that was his first one. Ever since that first one, everything in My emmerolagosi cookbook has to be edible food.

[00:03:48.16]
Colin: Wow. Yeah. Having done all my food photography for him, I never learned the hairspray and acrylic paint way. I just had to shoot edible food. And find ways to make it pretty.

[00:04:03.07]
Ned: That seems much more challenging, but also nicer because you can eat the food when you're done.

[00:04:08.29]
Colin: That is a very good silver lining, yes.

[00:04:13.02]
Chris: It's very different than photographing McDonald's, which is used with hairspray and is still not edible.

[00:04:17.25]
Colin: Yeah, and it's probably styrofoam, let's be honest. That's not what the burgers look like.

[00:04:22.06]
Ned: No, no, God, no. It's the saddest thing. Well, we are actually not here to talk to you about food photography, though that was a nice little scroll that we took there. We're here to talk to you about an episode that we did recently where Chris and I were talking about the technical interview and hiring process and our experiences with that and how it does seem broken. I think broken is the right word. You raised your hand and said, I have strong opinions about this. I do. Maybe we could start with just your personal experience, either from hiring or from being an interviewee.

[00:05:01.14]
Colin: What does that look like? Hiring, I was a manager briefly for two years. I did hire people, but they were SREs. It was mostly around system design questions about, Hey, what do we need to be concerned about if we need to keep something up? If this happens, what's usually a good indication of what's wrong? A lot of know the domain questions. I never ask them about, Have you written Groovy? Because why would anyone do that in their own time? That's me. I never ask them, Argo or Flux and why? Defend your decision. It was, Tell me what you know about this practice of DevOps, keeping the system up and running, making sure that everything's scaling properly, observability. Tell me what you know. We'll figure out the tooling later. Because if you know the concepts, adapting to the tools is pretty quick in my experience. And that's how it was with the people I hired. If they didn't know the tools, or if they didn't know the concepts, then it was probably going to be a steeper learning curve to learn the tools. So I never put them through some of the things that I went through.

[00:06:17.13]
Colin: I went through an SRE interview. Sre, very specifically, that's what I was interviewing for. Write an algorithm that turns any integer into a Roman numeral. This makes no sense. This has nothing to do with keeping the lights on. But okay, and I got through it. If I remember correctly, I mostly passed. But it was a really weird interview to go through. Other technical interviews I've had were your standard. Out of nowhere, for no reason at all, write a binary search tree from scratch. Okay? Failed that one. I did do the whiteboard out this massive feature. That was when we were still doing interviews in person. I was once handed printed Java on eight and a half by eleven, debug this Java. Good Lord. That was probably the worst. That was probably the, this is the dumbest of all the interviews I've been in.

[00:07:25.25]
Ned: Did you start with, well, I see the problem here is that you're using Java.

[00:07:29.28]
Colin: The problem isn't that it's printed. It won't run. But the key problem here is Java. Yeah, that was a weird one. And I asked, when would I actually... I pushed back on this one. When would I actually debug a printed block of code? And they were like, well, you need to be able to look at it without the help of the ID. And I asked, Well, when would I not have the ID? And I said, Well, the ID can help, but you need to know it good enough to spot the problems. Okay, well, I don't. And I failed that one. I did not catch all the problems because why would I catch all the problems? So that's my experience. My very first coding interview was one of the best I've ever had. I was given a GitHub repo, or given access to a private GitHub repo, and it was in 12 hours, post your fork, post a PR with your fork that solves this issue.

[00:08:30.10]
Ned: Okay.

[00:08:31.13]
Colin: And whether or not that was free work, I liked that interview because it was applicable to the job, and it was something that made sense. It was reflective of how we build things. And that was 2014. Until 2022, I have never taken a coding interview, that actually made sense like that one. And that was when I joined Maraki at Cisco. I previously worked in CX at Cisco. I I was an architect. I did some coding interviews, but most of it was system-designed to get the architect job. But then when I moved to Maraki, it was... I'm a developer now. I want to give up on being an architect, do not ever want to be an architect again. And the interviews that they gave me were all from the backlog. These were stories that had been completed. So it's purely applicable to the job. This is definitely stuff that you'll be working on. And it was great. It honestly was. It was open internet. Anything I wanted to Google, I could. Anything I wanted to stack over full, I could. It was, can you get this done in an hour? And it was problems that were specific to the domain.

[00:09:43.01]
Colin: It wasn't like, Hey, to write this join statement in sequel that anyone could look up in three seconds or ChatGPT in three seconds. It was, here's the structure for how our switch reports telemetry. We need to track downtime for all of our switches across this network and compare it to this other set of switches across this network. How do we do that? Let's work through it. And it made sense, and it was actually a lot of fun to complete. So stories like that. There were more, but it was things like that.

[00:10:17.01]
Chris: That's interesting because those probably don't qualify as having done work for free because you're talking about stuff that's already done and solved. They just want to see how you would be able to do it in a live environment.

[00:10:28.18]
Colin: Exactly. There's standard standard interviews that Maraki has. It's 200 of them, but there are standard interviews. They're maintained and they evolve. So people update them with new solutions as new solutions come up. But that's exactly how it works. It's this is a good thing that's reflective of what we do here. Let's put it in the interview library. And here's some solutions, different languages, and people can start using them.

[00:11:03.13]
Chris: In your experience with all the other ones that you've done, do you feel like there's any type of organizational rhyme or reason as to why they structure the interviews the way that they did? For example, the example of using the Java that's printed on paper, I get the idea, right? You want people to know Java well enough that they can read it, even if it's just on paper. But it falls apart because it's the old argument of, well, you need to learn math because you're not always going to have calculators, but you're not going to program without a computer.

[00:11:36.17]
Colin: Right. And that's why that one really didn't make sense just on face value. But taking it back a step, I was actually told by the recruiter, you don't need to know any specific language for this interview. You can come in with whatever language you want. They're all coding questions. So when I sat down with Java and just like, Oh, I don't know Java. I'm going to stumble through this based on, Okay, you're using a variable that hasn't been defined yet? I got that one. But other quirks of Java, my primary language at the time was JavaScript. So pretty big difference in things like memory handling and typing because JavaScript has none. And the list goes on in terms of the differences. So it was a real weird experience. Why they structure them that way? One of the One of the things I was told for one company I interviewed for was we do these computer science-focused interviews because once you're hired, you have three months to figure out where you want to work. You get hired into the in-crow, and as a member of the in-crow, now you can figure out what you want to do here.

[00:12:56.09]
Colin: That seems like on the surface, I think it sounds cool, but the more I think about that, the more I think like, that's a really weird setup where you don't even get to know your hiring manager in the interview process. The way I like to look at interviews is you're interviewing them, they're interviewing you. It's a two-way street. Because I did sit through one interview that I supposedly passed. I had a coding interview where I couldn't possibly tell you what the problem was because the hiring manager who was giving it, set up the coder pad, told me, All right, why don't you write out just the function signature and we'll talk through it? So I wrote out the function signature and he just talked through the solution as he typed it. And I was just watching him solve this problem. Some people just can't help themselves. And so a couple of days later, a recruiter called me and was like, Yeah, he said you did great. I was like, I didn't. I didn't do great. And I'm not working for that guy. I'm sorry. That was an awful experience. If he's going to just get hands on with everything I do, I'm not working for him.

[00:14:05.14]
Colin: So I rescinded my application on that one. But yeah, it's a really weird situation to say, Okay, we need people with this baseline skill level in CS before they can come in and build a dashboard for 10 executives that's super important or work on a hardware demo that is only ever going to be used once and doesn't need to scale the multiple devices. All the different things that these major tech companies do that are super niche and have very different problems that they solve, you can't just have a generalist interview approach and have it work for any job. It doesn't make a lot of sense to me, but at least that's what I was told. You take this generalist approach to CS, everyone meets this baseline, and now they can fit anywhere in the company. I don't think that makes sense.

[00:15:02.17]
Ned: Yeah, that seems not specific enough. Can you also go too far in the other direction and have an interview process that's too specific to the environment and the tooling that you're using today? I would say so.

[00:15:17.11]
Colin: But I think there's less of a risk than that. Migrating off tooling is a big decision, or it should be a big decision. It's something that usually, again, should involve everyone on the team. So if here's our tool set, right? Let's say we're using Java and we want to migrate to Rust. Okay, everyone's up to speed on Java, everyone's delivering now, We're going to start small with Rust. We're going to skill up everyone on Rust. It's not going to be a two weeks later, congratulations, you got hired two weeks later, now you're a Rust developer. You don't know Rust? This is going to suck. It's an iterative process that brings the whole team where it's meant to. If it's not, then that's an organizational problem. Still not an interviewing problem.

[00:16:13.06]
Ned: The tech check that you were talking about where you had an hour to solve the problem. I know that's one approach, but another approach is sending people home with homework to work on a project and then bring it back. Do you think that that type of coding homework is useful in assessing someone's skill, or are they just going to get someone else to do the work for them?

[00:16:36.09]
Colin: I think it is. If they get someone else to do the work for them, you're going to find out fast. We put way too much pressure on the interview process and not enough pressure on the being a good manager process. If someone cheats on their interview and they come in and they clearly don't know what they're doing, then be a good manager and address that. There's lots of ways to do that. If it's a matter of, Okay, maybe they aren't as skilled as they came across in their interview. Let's focus on what the issue is. Find the skill gap, skill them up. If it's, okay, they clearly cheated. Then it's a conversation with HR and you figure out who the next eligible candidate was. What I like about the take home is it helps eliminate bias. I always wonder about that hiring manager that just talked through the coding interview with me. And it was like, was there inherent bias in why he just gave me the solution? Could have been he was stressed, he needed to build out a team, he didn't care. But it could have been he was stressed, he needed to build out a team.

[00:17:43.27]
Colin: Oh, look, a guy, he must be qualified. And just decided I was. And would he have treated other people that way? People who look different from me, people with different backgrounds than me. So I think the more blind you can be as to who the interview is, the better it eliminates bias. If it's just a matter of deliver code, then have them deliver code.

[00:18:10.02]
Chris: Do you think some of that might be from the organizational/hiring side? It might be a little bit cynical in terms of warm body, burn and churn. We don't care if we turn over our our programmers every six months.

[00:18:24.19]
Colin: Well, I think there's the coding interview and then there's the It's a culture interview. How do they get along with the hiring manager? How do they get along with the team? One of the things that I've noticed is when it's just person to person, the bias tends to decrease quite a bit. If you don't know what someone else does, it's just, Okay, we're just going to talk. Whereas if it's, Let me interview you for this position that is super technical. An example I can give you. When my wife was looking for one of the interviews that she went through, they just asked her impossible questions to get right. I sat in on one of them. She told me, she was like, You got to sit on this and just hear what they're asking. So one of the questions was, What do you know about databases? Be concise. It's like, Who the hell asks that question? What do I know? So if you go into Sharding, well, you didn't talk about actual sequel. If you go into sequel, you didn't talk about Sharding and distribution structure. It's like, you can't get that right. And I've never been asked a question like that.

[00:19:37.17]
Colin: It's almost like, hey, you're not qualified. Let's prove it to you. So I think the more blind you can be in the technical sense, the more reflective it's going to be of the skills and eliminates bias as much as possible.

[00:19:54.04]
Ned: That's an interesting point where the tech check or the coding or interview or whatever it is, If you can do it in that, Here's some homework, take it home sense, instead of a person-to-person interview where you get to see them and ask them questions, it does eliminate some of that bias. I know I When I worked at a university, our hiring process, we would do a panel technical interview, which I felt so bad for the people we were interviewing because it was four of us ganging up on this poor person. That's rough. That's too much. It's overwhelming. But the one of the guys on our team, he would often come up with really technical, obscure questions, but he would only lob them at certain kinds of people, i. E. People that didn't look like him. It was very frustrating because in the wrap up when we were discussing how the interview went later, he would bring that up as a reason not to hire the person if they didn't answer that extremely technical thing about He would ask them about weird things in Soleris. Most people don't know Soleris all that well. So they would just be like, I don't know.

[00:21:10.20]
Ned: I could probably figure it out. But yeah, he would bring that up as a reason not to hire them. We'd have to push back and be like, But yeah, they were really cool and they knew all this other stuff, so maybe we should.

[00:21:22.27]
Colin: Yeah. I think if it's a reflective of the job, then you should be able to structure some We don't code in pairs, in groups with each other watching. That's pretty rare. Although I know there's a pair programming culture out there, but for the most part, with these technical interviews, it's for jobs where you are going to be coding on your own. So let them code on their own. And let them do the work the way they would if they were actually in the job so that you know how they'll perform in the job. And because of things like forking and timestamps and commit history, you can actually tell, when did they push this? Did they do it within a time frame? Did they do it within our parameters? You can run it through security scans to see, did they check all these boxes? You can run it through Sonr Cube and see, okay, how's the complexity? Did they write garbage code or is this something that doesn't smell too bad? You can have them write tests or send it through tests to make sure that it works the way you want.

[00:22:25.21]
Ned: What about the usage of AI coding assistance in these interviews? Do you think it's okay to use them, or should it all just spring from the developer's mind, the person you're interviewing?

[00:22:39.24]
Colin: Going back to my interview with Maraki, when they said it was open in internet. That makes sense because that's my life. I don't code without the internet accessible to me. That is a very rare circumstance. Maybe on a plane, but even then, I'll probably pay the eight bucks. For us to say, Okay, you can't use AI tools to prove that you're qualified for the job. It begs us a question, are we not allowed to use the AI tools in the job? If I were to go to my manager and be like, You know what? I'm going to prove I'm awesome by not using AI anymore to help me code. He would say, Please don't do that. That makes no sense at all. Why would you do that? Let's talk about this. But It's somehow become taboo for people to say, I want to use AI in an interview. There's a story of that kid from Columbia who cheats on everything. Well, it's not going away. If you're doing it and the interviewer doesn't know it, that's cheating. That's outside the parameters of the interview. But the solution here isn't to go harder on the no AI direction.

[00:23:54.27]
Colin: It's to accept AI isn't going away. We will continue to use it as we code, at least until something else replaces us, that it replaces AI or replaces us. That's going to be the norm. And so the interview, as it needs to reflect the job, needs to reflect, okay, you can use these tools. Maybe we shorten the time frame for what the deliverable is. Maybe we put extra parameters. Not only does it have to be functional, it has to be secure. It has to be production ready because we can get the purpose we do it. The reason we do it is we can get more done faster. Maybe the interview should reflect that. But to deny the use of these tools is going against what the job will actually be.

[00:24:43.08]
Ned: I look at the current hiring processes and I see these horror stories of an all-day interview, eight straight hours. Chris, you were talking about that during our episode. Aws basically kept you on camera for almost eight straight hours. I've also heard of just multiple callbacks, like two hours, then another one for two hours, then another one for two hours. Con, I'm curious, what are your thoughts on... What's the ideal interview process that isn't that eight-hour slog for an interview? Because they may already have a job somewhere else, but at the very least, they have a life.

[00:25:23.06]
Colin: Yeah, I honestly don't know. I'll be honest. This is one I've tried to figure out, what's the right solution? And I can't tell you. If you have a job, then there's only so many doctor's visits you're going to twice a week. Realistically, it becomes pretty obvious. Hey, morale's low. This person is suddenly going to the dentist. A lot. It's pretty obvious what's happening there. But then if it's an all day thing, that's brutal. Like you said in the previous episode, eight hours on camera is just awful. It's funny because when they handed me that printed Java, that was my last interview in a block of four hours. And even if I knew Java, I probably wasn't going to get it. Because by that time, looking at any code under that stress and constant context switching, I wasn't going to do well anyway.

[00:26:19.23]
Ned: I don't know.

[00:26:20.29]
Colin: I don't know what the answer is there. I mean, maybe that's why I do lean towards the take home assignment. Within the next 24 hours, we're going send you an email. You'll get access to this repo. An hour later, we expect a PR. You can figure out what that time looks like on your own. That seems to be, in my opinion, a good way to eliminate some of that.

[00:26:44.22]
Ned: Yeah. Now, that makes a lot of sense because from the technical assessment perspective, having just a piece of coding homework makes a lot of sense. That's not something that needs to be an interactive between you and the interviewer process. What you I really want that one-on-one time or discussion time is assessing cultural fit. Are you a good fit for this team? Is this team a good fit for you? That's something I would want to do in person. What are your thoughts on assessing that portion of things?

[00:27:18.00]
Colin: The cultural thing, I think, is important. It is. Getting to know your manager, being able to ask, or the hiring manager, getting the chance to ask them questions, and if possible, other people the team that you're going to be working with, asking them questions. What's your day-to-day life like? When you need help, who can you go to? What's your relationship with other teams that you depend on? Are there a lot of them? These are all questions that I would ask if I'm coming into a company to better understand, what am I getting myself into? And I want them to ask me questions just about my approach to different things, how I communicate. Do If that standard question, what's one disagreement you had with a coworker? If I say, Oh, yeah, that person sucked. They never got anything right. That's a pretty good indication. You don't want to work with me. But if it was, Hey, I saw their point of view, and you know what? I understood where they were coming from. We worked out a solution in ones and zeros that worked for both of us. Awesome. That's great. I think those are really valuable.

[00:28:27.21]
Colin: But yeah, the coding interviews, like the binary search tree one, the lady said, literally at the beginning, code me up a binary search tree, and then nothing. She just stared at me for 40 straight minutes.

[00:28:40.14]
Ned: Oh.

[00:28:40.26]
Colin: Giant waste of time.

[00:28:44.19]
Ned: Yeah. I feel like that sends a very clear signal about what it will be like to work there. Yeah. If your interview process doesn't reflect what it's like to work there, then you should update your interview process so potential candidates don't get the wrong idea because maybe it was awesome to work there, and that was just this antiquated interview process that they had in place.

[00:29:06.08]
Colin: Yeah, exactly. I agree.

[00:29:10.21]
Ned: Before we started recording, you had mentioned that your best interview you'd ever had was at your current job. Was that the Maraki interview, or were you thinking of something else?

[00:29:19.20]
Colin: That was at Maraki, yeah.

[00:29:21.27]
Ned: Okay.

[00:29:23.05]
Colin: It was story from the backlog, and that was with the Here's a set of switches. Here's their telemetry. Here's the structure it's going to arrive in. Let's figure out downtime. Now, compare it to downtime in this other set of switches that's got the same structure, but completely different data. A completely different set of downtime. Now, combine them. What's the holistic downtime look like? And it's like, yes, this makes a ton of sense. I'm going to be working at Maraki. I'm going to be working with telemetry on switches. This works. And again, it was open Internet. So if I needed to Google something like, oh, what's that method on this certain class? Or is it better to do it this way or that way? They had no problem with me doing that. So it was exactly how I would code in my day to day life. That was the great part about it.

[00:30:24.04]
Chris: So taking one step back, I'm wondering if maybe there's a missing piece here where it's not the interview, the technical interview itself, but maybe some of the pre-interview questions or the things that are done as a screening process before determining whether somebody should even get to that level that are either missing or not being utilized in the best possible way. From your experiences and from just being around the industry for as long as you have, does any of that ring a bell? Does it seem like just getting in the door should be a different, should be handled in a different way than it is? One of the reasons I ask that question is I often feel like these end up getting generalized and templatized because people have to do, say, I don't know, 40 interviews for the same position.

[00:31:13.10]
Colin: Yeah, okay. I see what you're saying. So a couple of things come to mind. Going back to some of the big tech companies and their standard like, thou shalt bin a research tree or Thou Shalt, and to this certain degree, then And they have these websites of, If you study this, you'll pass. And that is not true. They give you pointers like, know this algorithm, know that sort, know whatever. And so the screening process boils down to, are you interested and do you think you can pull this off? And they flash a lot of money in front of you and there's a big tech company name attached to it. It's like, yeah, I could do that. That sounds awesome. I'll be great. And then study, realize what... You've never written a sort in your entire life. Bubble sort may come to you eventually, but the rest of them is like, okay, this isn't going to happen. And you panic and you stress out over a couple of weeks, and then you fail, which is what happened to be with Facebook. I think there was a overpositivity, a Too much optimism in the screening process. But because it's so general, it's hard to nail down, Hey, this is the job you're going to be doing.

[00:32:39.26]
Colin: You pass that general interview, and that's one of the companies where, at least at the time, it was you pass, then you're in, and you get to pick your job. I didn't actually know what job I was interviewing for, and neither did the recruiter. It was, Can you pass this interview process? Great.

[00:33:01.18]
Ned: It seems like the exact wrong way to go about hiring people.

[00:33:06.24]
Colin: Yeah, I would say so. But I mean, they're known for their layoffs these days.

[00:33:15.07]
Ned: That is true. Several companies have been having layoffs, unfortunately.

[00:33:19.21]
Colin: I would say overall, it's the company culture. I would change some things, but that's just me. I don't run Facebook.

[00:33:28.08]
Ned: No, thank goodness. Well, We know who has that job, and he seems pretty miserable. Maybe rightly so. Well, this has been an interesting conversation. I love getting your perspective on hiring, what worked for you, and just this more general, maybe tech hire, maybe the tech interview part needs to be separate and asynchronous from the getting to know you cultural part. I like that as a takeaway. Is there anything that jumps out to you that you want to to leave listeners with?

[00:34:02.19]
Colin: My big thing right now, I've never been a fan of the standard CS algorithm interview, but now that we've all graduated from that to the AI being the conflict of the day, I think we really need to just adjust our interview processes and take a hard look at how can we best reflect what you will be doing when you get in the job. Does your hiring manager expect you to use AI? Then you should probably be able to use it in the interview. We need to, I think as an industry, adjust our interview process to reflect that. That's my 15 second rant.

[00:34:45.07]
Chris: It makes a lot of sense. I just have one last question. How do you move Mount Fuji?

[00:34:51.29]
Colin: You turn the globe.

[00:34:54.24]
Ned: I like that.

[00:34:55.28]
Colin: Not bad.

[00:34:59.08]
Ned: Colin, Are you a social person? If people want to connect with you, what's a good place to follow and find you?

[00:35:06.05]
Colin: Yeah. My day-to-day musings will end up on LinkedIn, and that's Colin J. Lacy. I look like me in my profile picture. And then I have a YouTube channel, Colin J Codes a lot. I've ignored it for the past few months, but I would like to get back to it this summer. So you can find me there as well.

[00:35:25.00]
Ned: That's my terminal problem as well. Awesome. Well, Colin, thank you so much for being a guest on Chaos Lover. Thank you for having me. And your listener, thanks for tuning in or something. I guess you found it worthwhile enough if you made it all the way to the end. So congratulations to you, friend. You've accomplished something today. Now you can go sit on the couch, print out some Java code, and attempt to debug it using a pencil and an eraser. You've earned it. You can find more about this show by visiting our LinkedIn page. Just search Chaos Lever or go to our website, chaoslever. Com, where you'll find show notes, blog posts in general, Tom Foulery. Yes, I actually started adding blog posts again, Chris. We'll be back next week to see what fresh hell is upon us. Ha-ta for now.

[00:36:13.09]
Chris: Actually, I always used to think it was Mount Fiji, and I was deeply confused because that's an island.

[00:36:21.21]
Colin: Isn't it a mountainous island?

[00:36:24.17]
Chris: You're not helping.