[00:00:00] Collin: Hey, Joel, have you ever interviewed for a job before?

[00:00:03] Joel: Uh, no.

[00:00:05] Collin: You've never interviewed for a job before?

[00:00:08] Joel: No, of course I have. Um, yes, I've interviewed for a job.

[00:00:12] Collin: How, how was it?

[00:00:13] Joel: Awful.

It's always awful.

[00:00:16] Collin: I agree. Uh, I feel like I've had so many interviews over the years. I've been in the programmer game for 15 years now, which is crazy cuz I'm obviously still very young and vibrant. Uh, so it feels weird to say I've been doing anything for 15 years. And I, I've had many interviews and I thought maybe a interesting episode would be talking through that. 

I recently had a contract that I expected to sort of go on, uh, end when I got a phone call, first thing in the morning, that was, Hey, so basically their budget changed and we're not gonna do this anymore. And so now I'm kind of thinking like, all right, I'm not in a huge hurry, I'm not like in trouble or anything, but I'm just like, okay, I need to find something new to do.

[00:01:06] Joel: That means interviewing.

[00:01:08] Collin: yeah, and so that means interviewing. So maybe we could just get into it and, uh, and, and I made a list of some things, but I think we can kinda wing it. What do you think the difference between a good interview and a bad interview is?

Like for, from your perspective, as the interviewee.

[00:01:25] Joel: Oh God. That is a good question. I. I don't know.

[00:01:31] Collin: Yeah, there's a lot of different processes, right? So there's the ones where they will have you do kind of more of a whiteboard thing is very common. There's also the ones where they will have you do like a CoderPad or, in the past I used to get where they'd have you come into the office and sit next to somebody and pair on something for a while.

Uh, one time they had me make mine sweeper. That was fun, I guess. Um, no, it was a boggle solver. Actually. It was to solve the game Boggle. And so that's another process. And then what, what else is there? And then there's also the process that is my personal favorite, where they just talk to you as though you're a person.

And, uh, try and get a sense for what your experience is and, uh, you know, what you know, or what you're, you're better or worse at. And if you'd be a good fit for the team. Have you experienced any of those ones or all.

[00:02:21] Joel: Yeah. All of the above. To be honest, I think, I really struggle with whiteboarding in particular. Those kinds of, uh, like design, they call them design interviews, but they're more like, it's, that's too precise. They're whiteboarding interviews. It doesn't matter if you can design stuff really well, it doesn't matter if you can, like, that's, that's irrelevant.

What's relevant is that you can draw boxes and circles, and do that live, and I find that really frustrating because that's not how I work. Even if I'm just thinking about an interface and kind of sketching it out, I do that in code immediately probably because I write such an expressive language, Ruby, that I don't need to have this intermediary language of like boxes and circles on a screen. So I never even go there. And so like going there for an interview is really tricky. Like, I don't know, I just find that to be difficult in particular.

[00:03:27] Collin: Yeah, I don't think very many developers I know think of designing software as like, first I will begin writing a UML diagram or something like that, and then I will start writing code. I have done that like very occasionally, probably after I read a Sandy Metz book because she's a big fan of it, and I'm like, all right, I'll try this.

Uh, but it was still in, like I have a thing that I'm, I've started working on it and I wanna like clarify like how exactly it should work, and maybe I'll make a little diagram at that point.

[00:04:06] Joel: right?

[00:04:06] Collin: Even that's pretty rare, but I have never, successfully anyway, like drawn a bunch of circles and boxes and things and then connected them and been like, there it is.

That's, that's the software.

[00:04:17] Joel: It's just not the way that I think. If I need to draw a diagram to explain some concept, I'll do that, but I'm. Already interpreting my own thoughts about the code structure and like the messages and objects that are gonna be involved, and then translating that into a diagram to help other people.

I don't naturally think in terms of the diagram, I naturally think in terms of the interface. And so where my head goes immediately is like, what does this feel like to use rather than, what's the implementation or like, how do I draw this on a diagram? So I find those kinds of interviews quite difficult.

Um, what about you?

[00:05:02] Collin: Yeah, I agree with that. I would separate out the pure design type interviews. I would say I've had some questions of that nature that were better than others. Uh, when it was really divorced from like software exactly, it was more trying to get it like my thought process of a system that was more successful.

So when I interviewed at Apple, one of the questions I had that I really liked didn't involve any code. It was, uh, basically, designing an airport luggage check-in system. So the idea was, people come to the gate, they drop off their bags, and then the bags have to get scanned through security, and then they have to get delivered to the gates.

And it was, he had all these conditions of like, all right, here's how it could get stopped up, and we could kind of talk through that and think about you know, how you could cue these things and how you could redirect from one scanning area to another, and it didn't involve any code, but it was sort of like what you're talking about.

But that's the only time I can think where I've had one of those where I actually really liked it.

[00:06:10] Joel: I had an interview at Shopify that was somewhat like this, but it was done in person and there was a physical whiteboard and a pen, and I think the, the interviewer at the time, he later became, um, one of my leads actually was, was like constantly trying to get me to draw on the, on the whiteboard and, um, I just, I just couldn't do it.

Like, like I couldn't draw, but I could talk through the problem and like, they were brilliant. They like, were like, okay, fine, this isn't happening, but we can still do a design interview and like just kind of do it verbally. And that was like, that kind of worked. But I've had other interviews where it's like, it just completely falls completely flat at that point.

[00:06:59] Collin: Yeah. I would say as an interviewee, it's good that the interviewer in that case was able to see like, this isn't really working for you, let's change gears. Cuz I think they knew you could do it, but that the like format was the problem. Uh, as an interviewee, I think a good tip is to just continuously talk and be like, just always just be making forward progress.

Like I think if it's drawing on a whiteboard, if it's talking, I think talking's the more important part. I've definitely interviewed other people before where they didn't talk very much and it's, I don't, I don't know how that was supposed to work. Like, the whole point is to try and understand somebody's thought process about like how to get through this problem you created for them.

So I would say I think that's a good tip. And I, it's one that. Probably has served me well, cause I've definitely done a lot of tech interviews where they asked me something like, I didn't go to college for this, or like, get a computer science degree or anything like that, like I'm self-taught, but because I was willing to like talk through the problem with the person like that and just continuously, uh, you know, verbalize what I'm thinking, I've gotten through a lot of interviews where I was presented with a sort of technical thing I maybe otherwise wouldn't have had direct experience with.

I was still able to kind of figure it out and like end up getting an offer. I think just because I was willing to like talk through it. And that's mostly what they wanna see. If the interview questions all had a simple answer like that and you could just answer it and be done, right. That's not really, like that doesn't do anything for them, they need to actually see you think about it. 

So I think those ones can be mixed. I have done less of those. I think I liked them more than you did, but maybe it's because mostly I've done less of them and the ones I did were okay. 

I think my least favorite is probably the kind of CoderPad type. You know, we're gonna send you a link and then somebody's gonna be in a chat with you, and then you need to like, write some code on this webpage, and then we will, you know, try and get through it that way. I really don't enjoy that.

[00:09:12] Joel: Hmm. I really do enjoy that. That's, that's my favorite kind. Yeah. Which is probably unusual, but like, that's the kind of interview that I feel I'm good at. I'm not good at making small talk. I'm not good at drawing on a whiteboard, but I'm, I'm pretty good at writing code and like breaking down a problem and finding a solution in code. 

I think if you are the kind of person that freezes when people are watching, then that's a terrible, terrible format. And you could be an excellent coder but also not be good at having people watch you, especially if you don't do a lot of pair programming outside of the interview process. If, if, if interviewing is the only place where your pair programming, I think that that probably feels.

A lot worse than if you've, if you've had a lot of experience like pairing with juniors or, um, pairing with, with other people.

[00:10:14] Collin: That makes sense. That's interesting. It seems like between us we could get any job, like if,

[00:10:19] Joel: yeah,

[00:10:19] Collin: could, if you could combine us, we're each good at the kind of interviewing. The other one isn't as good at, I mean, I do fine at those. I've gotten through a lot of those and, uh, gotten the job that way too. I just, I don't think I've enjoyed them as much, but, um, but that, that's interesting that you have the opposite, take on that, I think.

One that I've seen a lot of people do. I think there's two variations of this, and I, I'll talk about both of them. I think the first variation I'm thinking of is, uh, we're gonna have you either come into the office or do it virtually and you're gonna like pair program with us on a thing. That could, so that's a little bit different than the CoderPad thing where there's throwing a problem at you and then you have to do it.

It's where you're gonna work together on it. And I've had good ones of this and bad ones of this. Um, what, what's your experience with those?

[00:11:10] Joel: If, if someone's pairing live with me, it's usually quite good. What you can do if you are interviewing someone and you're pair programming is treat them like a colleague, not like someone you're quizzing. So like, actually helping them out when they get stuck, like a, like a colleague would do if they were pairing with you.

And I, I don't think that that compromises the interview to be honest. I think it's totally fine if I was interviewing someone and, you know, they were stuck trying to figure out some part of that process, I would help them out, but they'd see how they go from there, you know? Um, and I, I, but sometimes, uh, a lot of the time I think people, when they're doing these pair programming interviews, like when they're giving these interviews, it's very much like "I'm testing you," and I want to know that you can do this and they, they might like prompt you with questions, but they're, they're very much like, hands off, I wanna watch what you can do. And that can be a bit intimidating. I've been fortunate enough that the challenges that I'm working on have generally been quite simple for those, or like, interesting in some way.

Yeah, I dunno. I think it's pretty, you can be pretty unlucky though, right? And find something that you're just really uncomfortable with, like, I don't know.

[00:12:26] Collin: That makes sense to me. I think the point you kind of made that is worth noting is that there can be a wide range of quality for the pairing interview because you can have the one where they're not really pairing with you. They're really just kind of testing you and maybe prompting you a little bit.

And then you can have the one where they're actually pairing with you and it's like, oh, let's figure out how to do this thing. Like I interviewed at, uh, Thoughtbot once a really long time ago for an iOS position that I ended up not taking. Uh, but the interview was, they had me come hang out with the team for a day and me and the manager of this iOS team, he was like "Hey, I've never played with the augmented reality framework for iOS," that was newer at the time, and I was like, "I haven't either," and then we like figured out how to do it and we made a little app and then we went and like, you know, placed things in the world or you know, on our phone around the office, and that was fun. Uh, and that was a good experience of that. So yeah, I think that one can really go either way, and it really depends on the person doing the interviewing. I mean, I think all of them do, right? Like if you have a, if the person doing the interviewing does not, uh, does not do a good job, like it's not going to matter, um, which style it is, they're all gonna be bad.

[00:13:48] Joel: I think if you're doing that kind of interviewing, you are gonna get the best results by making the person you're interviewing feel like you're a colleague who is trying to help them. And trying to do stuff with them as opposed to someone who's assessing them, because that's when they're actually gonna show you what they're gonna be like to work with.

And that can be just completely different to someone showing you what they're like under pressure, feeling assessed, feeling like their every move is scrutinized.

[00:14:16] Collin: It's also good for you as the person who's interviewing, right? Because you're also interviewing them when you're doing this, so you get to see like what would they kind of be to interact with in that kind of a format?

Yeah 

[00:14:29] Joel: I think it's just really difficult for everyone because obviously they're not gonna be like that when they're pairing with you, when they're not interviewing you. So like no one's really telling the truth.

[00:14:40] Collin: Yeah, I mean, anything you do with an interview is always a. You know, it's like a science experiment version of working together. Like it's always going to be sort of artificial and some people are great at interviews but then suck to work with, and some people are terrible at interviews, but would've been great if you hired them.

And that's why I think the format that I really enjoy giving. And also as the interviewee is when I just talk to somebody and I think, I think coding questions are okay. I think they're probably more valuable with people who are a little more junior because you're trying to like figure, you know, that's, that's more like the part of the career they're in.

Like they're, you're trying to figure out like, can they code? Like what does this look like? Where are they? Like what could we have them do? But I think for senior engineers or above, I feel as though just, I think I can talk to another person and if they didn't know what they were talking about, I would know really quickly.

Like they couldn't, they couldn't bullshit me like I would know. And, and so to me, just talking to them and just trying to get the vibe of like, are we gonna get along? This is gonna be a cool person to hang out with all day. Like that's, that's a very good format.

[00:16:04] Joel: Yep, same. I completely agree. And also with like senior and above, you can ask them like, what's a project you worked on that you're really proud of? And. Let them talk and as, as someone who's being interviewed, that's a great question to receive if, if you've had that experience because you can talk about something that you did that you really enjoyed, you're really proud of.

You can talk about all the nuances and challenges that you faced. For me, I really like that kind of question, but you can't give that to a. , right? That's, so I think that's where interview processes need to be like slightly different. And I think it's, it's better in terms of like giving people more opportunities.

If with junior programmers it can be a lot more like, I don't know, assessing, assessing what they can do as opposed to assessing what they've done, if that makes sense.

[00:17:03] Collin: Yeah, and when I interview more junior people, I'm still actually really just kind of looking for like, level of excitement. Honestly, I feel as if I got somebody who had some of the basic skills, but they were really excited about it. As a junior, I can probably teach them what they need to know, like, it'll be fine. Um, you know, where somebody who maybe isn't as excited about working on this thing or doing this thing or just as excited about like engineering in general. I, I feel like that would, even if maybe they had a few more of the chops in place, that would be less valuable to me. I think excitement is something I'm really looking for, and also something that I think is probably really important to show when you interview with other people is that like you are somebody who's like really into this and want to do it.

[00:18:00] Joel: right? If you're a junior and you're interviewing and you're asking lots of good questions, like really thoughtful questions and that show that you are comfortable. Like, you know that you don't know everything. It's pretty important to know that you don't know everything. Uh, but you are excited to find out like you're excited to, to learn that stuff.

I think that goes a long way. Like to me, I think it's like you said, um, It's more about that excitement than actually this person has memorized, you know, all of the methods of array. It's kind of irrelevant. No one needs to know that.

[00:18:40] Collin: I actually think for my first few jobs at least, that probably is why I got them. Cuz it definitely wasn't that I was more qualified or something. I definitely wasn't. It was just that like I was. Well, the example I'll give is that the first interview I ever did for this internship, I got, uh, like right after the iPhone came out and they were looking for people to do this, was a group interview. And I can tell, like I definitely got it because I was by far the most excited about getting to make an iPhone app, like of anybody that was there. Um, cuz it, cuz I didn't know anything then about like, programming. I, I knew very little at that point and then I kind of like, continued to learn. So I can't think it was my qualifications in any way.

I think it was definitely just that I was so much more excited. 

So I mentioned, I think there's a second evolution of the we're gonna have you come in and pair with the team for a day interview, which is one I haven't experienced yet, but it is the, we are going to contract to pay you for an amount of time, like a couple of weeks or something, and then you can actually work on something with us and we'll pay you for it and see how that goes.

I've never done that one. Have you ever done this? Have you heard of this?

[00:20:00] Joel: No, I've, I've heard of it, I think, but I've never done it. I think like having never experienced it, I obviously don't know, but to me that sounds like a really excellent opportunity to get to know someone and if you're, if you're being paid a reasonable amount. I think that's great. 

What I, what I really don't like is when you get given a take home assignment that you're not paid for, but you're expected to spend several hours working on, and obviously like if you're applying at multiple places or you're working another job or you're doing other things that can just be like really awful.

Especially it's, especially if you're applying for a very senior position and you get given like a joke of a take home assignment, like build a Rails app that lets you add recipes to a page, right? And it's like this is something that I could do just by copying and pasting the Rails guides and I'm applying for a principal engineering position.

Right where I'm supposedly like gonna be solving complex design decisions, like, and, um, you know, working on, you know, I don't know, working at a completely different level to, to this like "rails new" and then like generate a few scaffold views. It's, it's just, it's just insane to me that that would be a blocker, especially for someone if like that has a lot of experience at another company that they can talk about, or has a lot of open source software, or like, you know, it's just, it's just, it's completely different I think at that level.

[00:21:40] Collin: I recently experienced this actually, which was that they wanted me to build a contacts directory app, and they sent me a little, it was an iOS app, and they sent me a, uh, I don't know, a, you know, a spec for it or whatever of what they wanted me to build. And this is a time where I was also starting this other thing that I just ended, so I was trying to like, get paid for that. And I looked at the thing and they were like, this should take you five to eight hours of coding or something. And I was like, that sounds like multiple days, possibly, right? It's like one full day minimum of making this contacts app, you know, the way you said that it is done.

And so I just didn't do that interview after that because, they weren't gonna pay me for it. So, I, I felt like it was not, I don't know. I felt like it wasn't valuing my time and 

[00:22:36] Joel: also, it's, it's getting you to, to put a hundred percent of that investment in. They're not sitting with you and, and building it with you and assessing you along the way. They're just looking at what you produced and that's not really gonna have much signal. Like, yeah, I can produce a very basic contacts app that hasn't had to address any legacy code or tests necessarily, or like complex design where you've just like, completely unsolved problems. You've just, just followed the guides and made a basic CRUD app, and that's just not a very, like, there, there's no signal there as to whether someone's actually gonna be a good engineer, especially at the like, kind of senior staff or, or principal level. Like, it's just, it's not even close to what you'd be working on.

[00:23:27] Collin: Yeah, exactly. For me, it was just like, so I'm going to spend, you know, one or two days of my time, working on this thing, and that's like the amount of effort I need to give you, but the amount of effort you're giving me, like you're give, you're basically saying we're going to give you nothing until after you have done all of this.

You may spend, you know, a day or two on this and, and we will then say, "nah, we're good." 

[00:23:53] Joel: Mm-hmm. We'll spend five minutes. Five minutes looking at the code you wrote. 

[00:23:57] Collin: Yeah.

[00:23:58] Joel: And then go with someone else.

[00:24:00] Collin: Yeah. It just did not feel. If I would've looked at the document and it would've said like, don't spend more than an hour on this, just like, make the best thing you can in an hour, I would've said, great, that's fine.

Um, but like five to eight hours, I, I don't know. It did not, at that time, it did not make a lot of sense to me, and it did not make me, uh, it did not make me feel good, I guess I would say.

[00:24:24] Joel: I think what's really different about a pair programming interview is you could be working on a fairly simple problem, but with some, with someone interviewing you and like pairing with you, at least they're putting in the exact same amount of investment of time that you are, so that that feels fair, but also you feel like you have an opportunity.

Like I'm not gonna spend eight hours writing something that they're gonna look at for five minutes. I'm gonna spend an hour writing something that they're gonna look at for an hour, right? And we're gonna discuss all of the questions along the way and have an opportunity to show how I think. And I think that's, that's very different.

[00:25:08] Collin: I absolutely think so too. And I don't know. I don't want to go work in an office again. I like being remote. However, I think there. Are parts of interviewing that were nice on site because oftentimes you would go and there would be a part where like you have lunch with the team or something like that, and you actually get to like, you actually get to know them a little bit over the day.

And I kind of miss that because I feel as though, you know, logging into a Zoom call or whatever so that I can do a CoderPad thing for an hour and then they're like, we're not gonna hire you or we are gonna hire you. Feels a little cold to me where it's maybe addressing one very small slice of what it would be like to work with a person, but it's not really addressing the larger slice of like, are they a chill hang?

Which to me, being a chill hang is probably actually more important than being really good at programming. If I could, if I could work with somebody who was like a total asshole, but they were, uh, like amazing at programming versus somebody who was like a really good programmer but also fun to be around, I think will probably be more productive even just because I don't know, everyone won't hate working with them.

Uh, so I kind of miss that actually, I think.

[00:26:34] Joel: How would you mirror that in a remote only company though? I was just thinking as you were saying that, I don't know how you would mirror that experience cuz you can't just like fly them out somewhere and like there, there happens to be someone who lives in this city who works for a company and so we'll just fly you out there.

It's, there is no office usually in remote only companies. And so I, I guess the closest thing to this is, is like what you were saying earlier, which is we'll contract you for a couple of weeks, which can work if you're, if you are out of work, and you're looking for a job, that can be an excellent opportunity.

If you already have a job, that's not a great experience, because you have to take two weeks off work and it's like to work, you're not taking holiday, and you might not get a job out of it anyway, so that, that's again, like has, it could be great for someone you know who's, who's completely out of work, but it could be, it's terrible for someone who is just trying to transfer.

[00:27:39] Collin: Honestly, I don't know why I haven't even considered that. That if you already had a job, how would that process even work? I think interviewing is really hard for the people doing it, and it's also really hard for the people being interviewed. And I don't think there are, I don't think there is a perfect process here.

[00:27:56] Joel: It's just, I mean, it's just an unsolvable problem. It's just so incredibly difficult. It's, it's all luck and intuition.

[00:28:03] Collin: I think It is kind of an unsolvable problem because, you know, for example, saying like, why don't we contract you for this period of time? I hadn't considered like, oh yeah, what if they had a job? How would you even do that? Uh, and. I don't know. Yeah, I don't, I, I don't know what the solution is there.

I, I know that I have, I know I've had better and worse ones. I think I do not like it when there are many rounds of back and forth and it's like, you're gonna talk to this person on this day and a different person on this. I kind of like it when it's, "we're going to have it all scheduled, and you're just gonna talk to the team, and then you're gonna have a decision," like at the end of the day.

I much prefer that. That's how Apple was. They just flew me out. And then I interviewed with three teams and I got offers from two of them, and they were all kind of the same, which was, you know, I have like four interviews and the manager takes you to lunch in the middle and, that day or the next day, like you're gonna know right away. I, I have felt like if that was good enough for Apple, that should probably be good enough for a lot of companies. But, I have interviewed with small startups that act like, I don't know, their interview process is so hardcore, and it's like, you have multiple rounds with multiple people and it just takes forever, and it's back and forth and there's take home stuff and I, I kind of wish more times the people doing the interviewing would just try and be respectful of the time of the person they are interviewing.

And I, a lot of the times it seems as though they're not.

[00:29:36] Joel: Yeah, I agree. I think you have to treat everyone that you're interviewing as an individual and assess them based on like, just as an individual human. So that means not offering a week of contract work or like not insisting on a week of contract work, if they're changing from another job and they don't have that time, they clearly don't have that time, but maybe offering it to someone who does have the time who you think looks pretty promising. Or like maybe if, if someone has no work that you can look at, then, then a take home assignment might be appropriate and they might appreciate the opportunity to show you something because maybe they've only worked on stuff that's completely closed source.

Uh, but if someone has a lot of open source software that they're, that they are happy for you to look at as a kind of assessment on the kind of work that they can do. Obviously, if you've got open source software that's really old, you might not be comfortable with that. You might be like, this isn't actually really representative of me.

But if you have, you know, representative software that's out there, why make someone go and spend hours working on something that is probably not going to show you their kind of problem solving capabilities. Anything like as well as, as their open source software is. So I think you can probably do a lot to customize, like make it about the person as opposed to the process.

Just, we've got this rigid process. We do it for everyone. Doesn't matter if you're, whatever. You're applying for this principal engineering position, you're never gonna be doing Rails new and like building a recipe app or anything remotely like that, but we're gonna make you do it because that's what we do.

And that's just like, you're not treating the people, you're interviewing as individual humans and you're just like treating them as data that has to fit through this rigid process, and I think that, that you can really feel that in a, in some, some interviews. Um, and also like if someone doesn't get the job, do send them an email to let them know as soon as you can as well.

I've had a bunch of stuff where like they just don't email you at all and you email back like a month later and get nothing in response, just completely, completely ignore you.

[00:31:59] Collin: Yeah, totally. Leaving somebody hanging is so disrespectful and just not kind, you know? Maybe they felt like it went pretty well and now they don't know and they have to email you back. Not emailing somebody back is just very disrespectful of the person you are interviewing and even the people you don't hire, like, they're going to go out in the world and talk to the people they know about what their experience was like interviewing with you, and I just think that's not the energy you want to put out into the world as being, you know, uh, we don't even email people back when they didn't get the job. That's, that's pretty crappy. 

So how is this different than with contract positions? Because a lot of what I've done recently and in the past has been contracting positions, and I find the process is often very different. Like, they might actually still want to interview you a little bit, I think it depends on the position, because a lot of contracts are basically just having you be a part of the team and treating you like every other employee, except they don't have to, uh, pay you some of the same benefits maybe. I've also had other ones though where, the contracting interview kind of was just me talking to them, and then I did the job and that was it. There wasn't anything to it really. There was no like, uh, it was just making sure it was a good fit. It was assumed that like, I could do it. That wasn't a part of it. Like how, how has that experience been different?

[00:33:25] Joel: I think, and I, I don't have any experience with this, but I think if you are applying for, uh, like an advertised contracting position, say through a recruiter or something, then you're gonna be treated very much in the same way as applying for a normal job. And that process is gonna look pretty similar.

But if it's more like, freelancing , because you've been found on the internet or something, and like someone already knows what you are capable of, and that's how they found you, then it can be very different and it's, it's usually just a con, like an hour's phone call. It's been my experience, like not, maybe not even that like 45 minutes on the phone, chatting about, what you're doing, chatting about their problem. They're not even trying to check whether you can do it. They're, they're more trying to check, are you interested in it? Is it something you want to do? Um, and like, do we get along? Do, do I feel like I can work with this person? And that can feel a lot better.

It's just there are, there are other downsides to contracting , but, to me, like the process of getting that kind of a contract feels a lot better. It feels, I don't know at, at least, at least for me, but I, I think early, early on in my career, it wouldn't have been like that at all, because I didn't have an experience, I didn't have anyone coming to me and saying like, "Hey, I wanna work with you because of this project or this project."

Uh, and so I think that can vary a lot as well.

[00:34:54] Collin: Yeah. It's interesting when you're doing freelance that yeah, they're the ones where you're applying for it and it kind of just is a job, like a regular job. But then they're the other category you said, and those are interesting because you're sort of more on like equal footing with the person, you know? It's not like they have something you want and like you want to get it.

Like you're sort of both just. Agreeing that like they want something from you, which is that you are a person who can do this thing they can't do and they have money and you want that. And that is the, uh, you know, there is a more equal kind of relationship there.

[00:35:34] Joel: I feel like they're also feel like they're fighting for your time as well. Like you might be booked up. There might be other people who want you to work on stuff and so yeah, it feels very equal usually, like we are, we're gonna come to an arrangement because, like, we have this project and we're gonna try and get you excited about it because we know you can do it.

That's a lot more how it feels to me.

[00:35:57] Collin: I don't know. Any other final thoughts on interviewing and interviews and, uh, anything with that?

[00:36:02] Joel: Yeah. I guess what, what would your tips be to someone who was about to do an interview or, or going through that process?

[00:36:11] Collin: I think my tips would be a couple I've mentioned, uh, on previous episodes before and also here. One is that I really like the trick of if they ask you to write a piece of code, write the test for it first and kind of talk them through explicitly laying out, uh, what the code should do in all these conditions.

And then I think that'd be a really good way to sort of, uh, suss out any edge cases that they may have as a part of this question just right in the beginning. And then you just have to make the test pass. And I think that's a really good tip that I would like to employ more, more generally. I think talk a lot.

Like, don't stop talking. Really let them know what you're thinking and just try and seem excited. And also just really don't, just try and seem like a cool person who'd be fun to be around. Like I think that's a lot of what they're looking for. People really want to be around other people that they enjoy, like they want, they want you to be a chill hang. And I think that that is a, uh, I think that is probably the most important interview tip. Like, don't be adversarial, don't be like, just be cool. Just like be fun and excited and like you want to be there, and then they'll want you to be there.

What are, what are your tips?

[00:37:30] Joel: I don't know. I think one of them is if you are quite new to either programming in general or maybe the specific kind of programming that you're applying for, and you don't have, like a bunch of projects that you've done, say at another company that you are allowed to talk about, then I think it can really help to spend some time building something, like build some app for yourself that does something interesting.

Uh, for me, this was like crucial in terms of how I got my job at Shopify. Pretty much like Shopify was my first proper Ruby job and I got that job only a few years into learning. Like not even like, I think maybe like a year into learning Ruby, and I think a large part of that was the fact that I had built this app and I had this project to talk about and it had interesting things and like challenges and things.

So I had just built an app that had, for example, um, I was doing some interesting stuff with encryption and exploring like basically, uh, early encryption, how Rails now has, uh, encryption on in the database. It was very similar to that. Only it was using user derived keys, so it would derive keys for your password.

Um, and. , if you were, if you were logged out, there would be no way of the server knowing like what your stuff was when you, when you logged in for like the, a very, very short amount of time, the server would have to like do whatever it is to decrypt your data for you. Um, but that was, that was interesting, like talking about the trade offs to that and how it's like it's not quite end-to-end encryption.

It's providing something additional. I think just having something and this, this app was so incomplete and you know, it, it wasn't polished or whatever, but it just gave me something to talk about, and something is better than nothing. I think that can really help. And obviously if you're more experienced and you've been in the game for a while, then I think you'll have that already, and so it's quite easy to like talk about these projects that you've done in the past and the challenges and whatever, how you solve various problems. But yeah, I'd say if you're new, try to just do something at home. Like if you, if you wanna build a library, if you like to do something interesting, do that. If you wanna build an app to do something, do that. Um, it doesn't have to be anything you would ever publish, but, for me, I think that was the best thing.

[00:40:16] Collin: Yeah, I think that's a really good tip is having something you can show. And I've actually thought of that before, like when I've gotten these, spend five to eight hours making this little thing, is that I kind of was offended to do it when prompted that way, but then thought maybe I should actually go do something like that and just put it open source on GitHub.

So that way the next time someone asks, I'll be like, well, is this okay? Like kind of already what? You're very similar to what you're asking for.

[00:40:43] Joel: If you're out of work, you could either be spending, you know, four or five hours per like company that you're interviewing at doing their own challenge, or you could spend maybe a bit more time building something a bit more thorough and putting it on GitHub. And then you have some open source thing to point to that and that you can talk about.

And I think this kind of goes back to the nonsense of companies requiring you to do their challenge and fit their process, even if you have like a decent amount of code to show them and projects to talk about. Um, so don't do that if you're, if you're hiring people, cuz that's, that's unfair.

[00:41:32] Collin: Yeah, totally. I think that all makes sense. Uh, yeah, interviewing sucks. I think we both agree, but at least we've been able to talk about it, so I feel a little better now.

[00:41:42] Joel: Yeah, me too.

[00:41:43] Collin: So before we wrap up, I just wanted to say, if you like the show, thanks for listening and also tell your friends. Leave us review, hit that little star in Overcast any of that, uh, would really help us out. We're trying to grow the show, you know, we're still just kind of starting out, so that would be great. And we will see you all next week.