Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--in the shed--Rupert and with me is Chris--in the booth--Coyier. Looking good, Chris.

Chris Coyier: Hey! Thanks. This is going to be a good one. We haven't had a guest in a hot minute, and we have a guest this time. We have Emma Bostian. Hey, Emma. How are you?

Emma Bostian: Hi! I'm very flattered to be here, especially if you haven't had a guest in a while. How are you?

Chris: Good. We're great. Yeah, I don't know. Just random. Sometimes we go on little rollercoasters of doing it and not, but this seemed like an excellent opportunity that lines up a little bit with a book that you've released that everybody out there can buy now called De-coding the Technical Interview Process. The URL, of course, will be in the show notes. It's at technicalinterviews.dev. Nice domain name. Good buy there.

Emma: Thank you so much. Right? I was just going to say that my inherent incessant need to buy every domain that I come across has finally paid off.

Chris: [Laughter]

Dave: [Laughter]

Chris: That one worked out. Actually, did the project after buying the domain name.

Dave: A return on investment. Okay.

Chris: It is a bit of a crossover podcast because you are, of course, on the Ladybug Podcast as well. Right on!

We've got to talk about interviewing. I think that's probably going to chew up a lot of the time here because that is a fascinating subject that so many people are interested in, probably because isn't there just a lot of people in this world who basically are worried and scared, perhaps, about what is in store for them during this time in their lives? Is that who you're talking to in this book?

00:01:58

Emma: Yeah, absolutely. I wrote this a year ago in the midst of -- not in the midst. At the beginning of COVID when a lot of developers were losing their jobs. Everyone was kind of thrown into this panic mode of, how do I study for technical interviews, especially if I don't have a computer science degree? To be honest, in my experience, there really wasn't a resource for non-CS degree developers to go to, especially Web developers. That's kind of why I wrote this.

Chris: Yeah. Non-CS degree meaning someone in the world who didn't major in computer science in college.

Emma: Right.

Chris: Are those people--? If you did, is this world just easier for you? Do you feel like the technical interviews out there edge that way?

Emma: I would say yes and no. Yes, it's easier for you to land a job interview as a whole just because oftentimes these big companies are searching for people with computer science degrees because there's this innate or subconscious bias that people with computer science degrees are more knowledgeable or will hit the ground running faster, which is total BS in my opinion.

But, in my experience, having a computer science degree, the practical knowledge of how to be a Web developer was not there. So, people who are self-taught or went to boot camp I believe were more successful than I was when I started in my role because all I had was Java and computer science algorithms and data structures.

Chris: Right on. Right on. You're kind of rooting for the boot campers in a way, right?

Emma: Absolutely.

Chris: Yeah! Yeah. Yeah, me too. I think that's cool. I think what's particularly cool is how self-selecting it is. You know? People do it because they really want to. They're attracted to the idea.

Emma: There was a thread on Twitter the other day with Adam Rakus. He had made a comment about how if he saw a huge stack of resumes, how do you siphon out candidates who will be successful in a role, and how do you prioritize them as interviews? He made a comment about, like, "Oh, well, if I saw a resume with a candidate who went to Harvard and graduated with a computer science degree, I would prioritize them."

I'm like, do you understand the privilege that comes along with that because not everyone can go to college at all, let alone Harvard. Just become someone comes from a college degree or an ivy league school does not mean that they have the skills necessary or the drive, for that matter.

Chris: Right. Right. How would you do that, then, if you were? Is the answer that you need to interview them because you can't just look at a stack and just be like, "Yes. No. Yes. No. Yes. No"?

00:04:54

Emma: Yeah, that's hard. Realistically, how do you siphon through all of these resumes without using these automated tools? Many companies don't have the resources to check each and every resume individually. But in my experience, having a solid portfolio of work that's varied and it demonstrates your different skillsets, that's going to be way more valuable in landing you an interview than just listing technologies on a resume.

Chris: Yeah. Right on. Take us through a little bit more about the book, who it's for, and what you're going to get out of it.

Emma: Yeah. My primary market -- I don't even like the word market because it seems very inhumane, I guess, or very objectifying.

Chris: My target audience is the--

Emma: Yeah. Yeah. [Laughter] The people that I wanted to help.

Dave: User persona A is who?

Chris: [Laughter]

Emma: [Laughter] Oh, gosh. The people I wanted to reach were the people that I see myself in five years ago. Where was I five years ago? I was struggling. I was crying almost every day at work because I didn't understand development because I couldn't find beginner-friendly resources that really spoke to me.

I think we forget that understanding how to learn is a skill. People learn in different ways and oftentimes the most successful way to learn is the most difficult. And so, I wanted to present these really high-level concepts of sorting and searching algorithms and balancing trees and all of these concepts in an approachable manner with diagrams.

If you are listening to this and you've always struggled to understand merged or load balancers and systems designs, things like that, I wrote this for you. I wrote this as a resource I wish I had had five years ago.

Chris: Gosh. A load balancer is a great one because, even now -- I think I said on a previous podcast -- nobody has bestowed this on me because I only have worked at pretty small places. I feel pretty senior. I've been at this a couple decades now. It's like my hobby and my career. I know a whole bunch of stuff about making websites, I'd like to say.

I'd like to think that I would -- well, I don't like to think it. I hate to think it that I would choke if somebody asked me, "Describe a load balancer." I'd be like, "Uh, it, like, requests come in and it gives them the different services."

Emma: "It balances loads." [Laughter]

Chris: Yeah. [Laughter]

Dave: Yeah.

Chris: It balances loads and then I jump out the window.

Dave: It takes the load and then it balances that load.

Emma: [Laughter] What more do you need to know?

Chris: What if you know even less than I do?

Emma: Yeah.

Chris: Is the goal then to fake it or is the goal to have enough of an understanding that you could talk about it at least semi intelligently? What's happening there?

00:07:44

Emma: I mean realistically, there are two ways to study for a technical interview. The first is, cram the night before, which superficially is pretty "successful" in that it allows you to short-term memorize a lot of information at once but not necessarily understand it. This is quite ineffective.

The better method is to study a little bit over a long period of time using contact switching as a tool. Contact switching is the fastest way to burn this information into your brain and understand it at a deeper level because it allows you to access these pieces of information more often and that solidifies it and makes it easier to recall and recognize these things. But again, that is the longer and more strenuous route. That is the preferred method of how you would go about it.

What was the original question? I'm totally talking in circles now. [Laughter]

Chris: Well, it was kind about, because there are so many great examples in the book, but this is one of them. Let's say you're asked some question. Let's frame it. Let's say you're being interviewed and the interview says, "Tell me what you know about load balancers," or maybe something more specific.

Dave: Linked lists.

Chris: If you had to write a load balancer from scratch, what would that be?

Emma: Mm-hmm.

Chris: You don't know. You're a junior. Is the correct answer to just be like, "I don't know. I have never written a load balancer." Or is the correct answer to be like, "A load balancer is an intermediary server that," blah-blah-blah?

Emma: Right. First of all, if you don't know the answer to something, it's always best to admit it. But then make an educated guess if possible. If you have a good interviewer, they A) will not be asking you trivia questions and B) will be like, "Okay. It's not worth our time. Let's explore a different area that you're more confident in." That being said, it's always better to understand the concepts behind these things as opposed to memorizing code or memorizing definitions.

I struggled with asynchronous JavaScript and having to explain what a promise is. That really got to me. What I came to understand after a while -- I remember I was interviewing with Gatsby at Gatsby with Jason Lengstorf. He asked me, like, "Oh, can you--?" He gave me a few options, which I appreciated that he gave me a choice of which question I wanted to answer.

Then he said -- one of them was, "Can you define a promise?" It kind of clicked for me in that moment. I gave this analogy of being at a restaurant and ordering food. The waiter takes your order and brings it back to the kitchen. In the meantime, you can continue to talk with your friends and drink your drinks and all of that stuff. Either they'll bring you your food or they'll come back and say, "Oh, we're out of pasta. Do you want to order something else?"

For me, it was really like, "Oh, crap! This is what I need to be doing to really understand these things is relate them to real-world scenarios."

Chris: Hmm.

Emma: Yeah. In the past, I'd just been memorizing descriptions and it really did me a disservice.

Chris: I would be impressed by that, I think. Not that I've interviewed that many people. Although, I will say I have two interviews this week, so I might have to mine you for some ideas for good interview questions.

If I ask someone to describe promises to me and they talked about a diner, I'd be like, "Hell, yeah. Good job. That means that you think abstractly and you understand this deeply enough that you could then relate it to other likewise abstract things."

Emma: Mm-hmm.

Chris: You're more useful to me, in a way.

Emma: That's what problem-solving is, right? It's taking your experiences solving specific types of problems and being able to recognize when that same type of solution will apply to new scenarios.

00:11:16

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Flatfile. That's Flatfile.io.

One of the worst ways to spend your time is manually formatting spreadsheets. Thankfully, Flatfile has created Portal, the elegant import button. Flatfile Portal is a turnkey data importer that automatically formats, validates, and transforms customer spreadsheets so that data is ready to use in your backend. Portal integrates with virtually any application and, in minutes, can upgrade your customer data onboarding from emailing Excel files back and forth to importing even the messiest of data correctly on the first try.

Start for free at Flatfile.io, and high-five for the sponsorship. Thanks so much.

[Banjo music stops]

00:12:14

Chris: So cool. We'll do some more example ones later because it's kind of a fun thing. You interviewed at Gatsby, which I think is probably kind of dream job territory for a lot of devs out there that maybe use that tool and think, "Oh, gosh. How cool would it be to work on some big tool like that?" especially when you hear news like they just took $20 zillion in funding. You're like, "Oh, dang. I want to ride that rollercoaster," or whatever it is.

Still, in the grand scheme of things, probably not as big as more people probably dream about working for Microsoft, IBM, Google, or something. Is there any kind of different games you've got to play? Is it just a different world when you're interviewing for a Google than it is for interviewing for a Gatsby?

Emma: Oof. That's a good question. My experience is mixed. These FAANG companies, FAANG-style companies, large companies, they typically will have interviewing committees whose whole purpose is to evaluate the process and make sure that the questions are fair and whatnot. They evaluate related skills. In my experience, those are the best processes out there. Their goal is to reduce implicit bias.

Ironically, the interviews I've hated the most and absolutely resented were from startups who had something to prove. They wanted to be just as cool as the FAANG-style companies, and so their process was much less organized and much more strenuous, in my opinion.

Chris: Really? They were almost the worst.

Emma: Absolutely.

Chris: There's some jerk at the small company that heard that, at Google, you have to guess how many gumballs fit in a bus, so they asked you how many marbles would it take for a hippopotamus to slide around the state of Arizona or something. It turns out that they're just a dick. [Laughter]

Emma: Right. Yeah! Absolutely. Let me tell you. If you're a dick to your candidates, they're going to fricken' remember it and they're never going to interview with you again, because I had this happen to me.

For example, Google is notorious for these brainteaser-style questions that I can confidently say they don't do brain teasers anymore. I will say their data structures and algorithms are very heavy in data structures and algorithms versus Spotify. What we try to do is make our questions relevant to something you would do in your domain and also day-to-day.

A Web developer going through data structures and algorithms, they should be able to understand data structures as they pertain to Web development and not just, "Code a linked list or a binary tree in JavaScript."

Chris: Mm-hmm. Okay. What would you ask? You would need to know that. If you're going to be a dev at Spotify, you should know your objects from your arrays, let's say.

Emma: Mm-hmm. If you're going to be a developer anywhere, I think that's a great skill. That being said, hopefully, the companies are recognizing the type of position you're applying for and gauging that subjectively to that role. A super senior engineer is not going to be the same criteria as a junior-level associate.

00:15:16

Chris: This red flag stuff is interesting. I've heard this and it seems to be true that this is a two-way street, right? You're being interviewed because obviously you want to paycheck and want to move up. It's important to you. Probably, you're the one, in a sense, that's trying to get something out of the company, but it really is both ways, right?

In a sense, you're interviewing them too because if you discover during this process that this is some kind of horrible place to work, you should maybe consider not working there. I know that has a degree of privilege to it, too.

Emma: Yeah.

Chris: Is that true? Are you looking for red flags?

Emma: Absolutely. I think, absolutely, you should be. I think a lot of times candidates see these big named companies and they're just so excited to even be talking to someone from them that they forget they also need to be conscientious of whether or not this is a safe work environment for them and whether they'd enjoy the type of work they're doing.

For me personally, let's say I get a job offer from Google but it's working on a project that would absolutely make me miserable. Do I really care? Do I care that it's Google or would I rather be happy? Would I be happier working at a smaller company with not as much global notoriety but I love what I do?

Chris: Yeah. That is tricky. Oh, I don't even know. Especially because the salaries, those top-tier companies, they just pay well. They just do, and to some degree, they kind of have to because, you know. I don't know if this is globally true, but kind of because they want really top-tier candidates but it also can be kind of a bummer to work there because you're working super hard and you're trying to stand out in the crowd.

I don't know. It seems like there's so much competition at those companies that salary is one of the things that they can compete on and win because they have bucketloads of money to compete with. If you're a startup and you're trying to get somebody top-tier, the way to get them is being cool (whatever that means), offering stock (which is tricky but possible), and then stuff like our work/life balance is good. I don't know.

Emma: Mm-hmm. Yeah.

Chris: We work from home. That's cool, right? Although everybody has that now.

Emma: Yeah. I think, as well, during your career, your priorities in what you're looking for in a job, in a company, are going to change because, for me, the first few years of my professional career, I was more concerned about salary. That was where I was at in life. I had some debt I needed to pay off, so salary was the most important.

Now that I am financially stable and I'm back on my feet, the most important thing for me is team rapport. Is that the right way to say that? I don't know. The relationships that I have with my team members, especially working remotely in a foreign country, my teammates here often are my friends and, to some extent, my family.

It's okay if you're not making the same salary as a Netflix or Google engineer out in California. Is that the most important thing to you? If it is, okay. Maybe go ahead and apply to those roles if you're okay with the company culture maybe not fitting exactly with you. You have to really discern that for yourself.

Chris: What do you think, Dave? Could you hack it at Netflix?

Dave: Exactly right, the stage of life. I'm a dad, have kids. I've got to power it down at 5:00. I can sometimes work a little bit later, sometimes do, but I've just got to power it down.

I think life obligations kind of creep in, too, and kind of gauge how much stability you want, how much benefits. Yeah. Can you roll at a startup pace for the next whatever season of your life? I don't know. Maybe not. Some people can't.

I have one friend. He worked at a startup and he was tired of them changing their mind every month. He just was like, "You know, I'm done." [Laughter] "I'm going to stablecompany.com, or whatever, because this is sort of exhausting to kind of just chase a mythical money pony."

Chris: Mm-hmm. Yeah. I lost a candidate just the other week, like, "I don't want to work at a tiny company. I want to work at a big company. I want to be lost in the sea of employees." [Laughter]

Dave: Yeah.

Chris: Okay. Sorry. Can't offer that.

00:19:38

Chris: One thing from the book that I thought was an absolutely excellent thing to ask a client -- I don't know how often this appears in interviews or where you got this, necessarily, but it was around the idea of infinite scrolling.

Emma: Hmm.

Chris: Which, wow, what a juicy one.

Emma: Yeah.

Chris: I feel like it could work across so many different spectrums of building websites.

Emma: Yes.

Chris: What's that one about? How would you maybe do that if you were an interviewer?

Emma: Yeah. Yeah, it's just kind of like -- I like to relate these to things that candidates might see in real life.

Imagine you're building an Instagram-style application where you can scroll and see your friends' photos. As you scroll, more and more load. This would be a cool systems design question, but it's also a really great Web UI question because there's so much user experience that you can dive into here. Also, visual design.

I've had this asked before in an interview when I was the candidate. I talked a lot about UX design and all of that like, okay, at what point do you make a request for more images? How many are we loading from the beginning?

Chris: Right.

Emma: What is the most valuable property of the system? Is it reliability or is it speed, like responsiveness? For this, I don't think users care if it's very reliable because every time they load new images, they're going to see different things from their friends, right?

They care more about responsiveness and how fast these images are loading. How can we minimize these images so that we're not losing any quality but they load a lot quicker? What about users in countries or users on low data plans, things like that?

There are so many different aspects that you can touch here. I would suggest catering it to the role at hand. If it's a Web position where you'd be interfacing with design a lot, focus on UX and accessibility is a big one, too.

Chris: Oh, so good because of that cross. If I just threw the ball out there as an interviewer and said, "Talk to me about infinite scrolling. What goes through your mind with your skillset?" I think that's what I'd be listening for.

Now, this is not what you wrote about. I'm just riffing here a little bit. I would be impressed if you talked to me about all that, if you talked to me about the speed of loading and the success criteria of what is this good, what the alternatives would be if we don't do this. What APIs are necessary to make this work both ones that we have to build and what ones are available in the browser if you're like--I don't know--I'd attach an intersection observer to the thing. I'd be like, oh, interesting. What about the back button?

Dave: If somebody knows about intersection observer, I'm hiring.

Chris: Yeah.

[Laughter]

Chris: Yeah, sure. But wouldn't that be -- you'd learn a lot about a person, I think, if the answer delivered to you was listening to them tackle this big idea on how cross it is.

Emma: Mm-hmm.

Chris: I think that would be neat, not that everybody needs to have that wide degree of skill. You said it'd be nice to scope it to what you're actually interviewing for, but that is great. It's a great interview.

Emma: Yeah. I think it's also important to approach interviews -- if you are an interviewer, it's important to approach an interview as an opportunity to learn from the candidate because so often -- like, I had a systems design interview today and the candidate mentioned things I hadn't even thought of.

Chris: Hmm.

Emma: He's doing backend systems design, and he's over here talking about user experience. I was like, "Oh, yeah!" I told him that. I go, "I really like that you said that. I think that was a really great comment. It's very important, and I hadn't even thought of that."

That's how we approach interviews at Spotify. We approach it as an opportunity for learning from our candidates and also as a conversation.

00:23:28

Dave: That gets me into the idea of generalist versus specialist. They're a backend position, right? But then they kind of know more front-end UX domain sort of stuff. What are your thoughts? Is it better to be a specialist or is it better to be a generalist? Or good F'in luck. I don't know.

Emma: Yeah.

[Laughter]

Emma: I used to think both were completely equal, and I think that they still are. I don't think it's fair to say one is more beneficial than the other. My personal interpretation is a younger developer newer in your career, it's better to be a T-shaped engineer where you have a primary focus of Web development, and then you have knowledge into both UX, visual design (maybe), or the backend side of things. You have knowledge about the tangential spaces. The more experienced you get in your career, I think that's when you can really specialize and become more vertical.

Chris: Hmm. You have a bunch of personal experience with interviewing, both as being interviewed and doing interviewing. Surely, since the publication of the book, you've heard from people, too. I wonder. Have you heard any real whacky stories of interviewing disasters or anything?

Emma: I don't. My inbox right now is like 200 unread emails. It's funny because I'll do 20 a day. I'll respond to 20 because I read all of them and I respond individually. Every day, they're back up over 200.

Most people are just saying that this was really useful to them and that they failed at an interview, but they're hopeful. This gives them motivation moving forward. I haven't heard any really bad horror stories, per se.

Chris: That's good.

Emma: I've had a couple myself, but that was again back to this egotistical startup guy who was badgering me with trivia questions at 6:00 a.m. my time during the recruiter phone call. It was absolutely horrific.

Chris: Wow.

Emma: But, yeah, I haven't heard any super bad stories. I've heard some really nice things that this helped someone land a job offer, and that's really my goal.

Chris: Yeah! That's the best, isn't it? Look at that.

Emma: Yeah.

Chris: You helped somebody actually get their foot in the door, get started.

00:25:47

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Around. That's Around.co or follow the link in the show notes.

It's a new video calling app that's very different from the other video calling apps out there, I'd say. They say this and I think it's really true. It's designed for collaboration more so than for meetings. It's not this big rectangle and you're just looking at everybody in the rectangle.

Each person that you're talking to is this floating head. You see their face cropped into a circle and then part of the UI and UX of it, there's a lot of fun built into it. You can apply filters to it and stuff. It just feels a little bit less fatiguing to know that you're just a talking head on somebody's screen. They're not looking at every pixel that your camera is picking up. It's really clever and it feels really nice.

Yeah, they say it's more for collaboration. I think that's true. It's very easy to fire one up. You fire up the app, get a link, share it with somebody, you're in the meeting. All kinds of security built into that. You can make sure that you have to approve them before popping in. Nobody is going to bomb your meetings anyway, but lots of protection there.

Or if you're in Slack, you just type /around. It pops open a meeting. Everybody clicks into it. I'll probably use that a billion times. That is how things work. There's that pseudo-real-time thing of Slack. "Hey, can we chat this out?" Boom. /around. You're in there. It's great.

There are lots of fun UI and UX touches as a part of it that's great. The screen sharing is really nice. it's everything you expect in there. You can share the whole window or select a particular window to share.

It has the control aspect built-in, too. If somebody is like, "Hey, let me take control for a minute. I'm going to type here." I do a lot of pair programming that way. It's got all those features built in.

Out of the gate, it's just a great video call app and it just seems like it has a super bright future because they just really got the details right. Thanks, Around.

[Banjo music stops]

00:27:59

Dave: Are there things like -- your book is about acing the technical interview, right? There's obviously some human qualities somebody needs to possess. Do you have any tips on how to, I guess, not be a total schlub or something?

Emma: [Laughter] I have some books I recommend. There are some really cool books about productivity. Atomic Habits is a really good one if you're looking to convey the fact that you like to learn new skills and you have a really solid plan on how to grow your skills.

My favorite book of all time is called The Culture Map. It's by Erin Meyer. It's all about how to work with cross-cultural teams, which is extremely important now that we're all remote. If I hear a candidate who discusses empathy and communication, those are like, yes, absolutely, I want to work with you.

We forget as well that oftentimes -- I've never had an interview that wasn't in English. I think we take for granted the fact that we speak English as a first language, but many candidates don't, and so there's a lot of anxiety with them in terms of how to communicate effectively.

Chris: Hmm.

Emma: If you are an English as a second or third language candidate, I recommend reading The Culture Map because it's going to help you not empathize but communicate in the manner in which your American--if you're being interviewed by an American developer from the USA--how they think because we are very low context communicators, meaning we like clear, explicit communication. We like redundancy. We like to have all the validation that things are going the way that you want them to go.

But many cultures are taught to read between the lines, to "read the air," and so they're not perhaps as communicative or explicit in their communication as we are. We could see a candidate who is maybe quieter or not as expressive in their thoughts and just think, "Oh, they're a bad communicator," when in reality they're just communicating the way that they're taught and they're used to.

If you're an interviewer, I highly recommend reading that. Also, if you are a non-native English speaker, I'd recommend reading that as well. Not non-native English speaker. If you have interviewing with an American company, I'd recommend reading that as well.

Dave: That's a good point because I lived in Japan for a while, and I read a book on Japanese culture while I was living there. It was weird because I felt like I was reading a book about myself. [Laughter] It was kind of like passive aggression or working around the problem, if you think of the problem is in the center but you just kind of dance around the problem and "beat around the bush," as we call it in English - the idiom.

That's how they get things done there. They all just kind of pepper, like, "Hey, has anyone thought about that?" Then some other person is like, "Oh, I don't know." Then it just kind of drifts there for days or something.

Emma: Mm-hmm.

Dave: But that's how you bring up a problem, kind of gently over time. You just kind of zero in on it eventually.

I was like, "That's sort of how I operate." But in America, that's called passive-aggressive behavior -- or whatever -- and that's bad. You should just come out and say, like, "Oh, I think we should F'in change the navigation."

Emma: Mm-hmm.

Dave: That's like, "There's business."

Chris: Are we the most blunt culture, Emma?

Emma: Yes.

Dave: We might be the worst.

Chris: Yeah?

Emma: No. Well, so, we are low context communicators, but we are indirect negative feedback givers, which means we do this compliment sandwich where, if you're going to give negative feedback, you try to wrap it in something a little less harsh. We use down-grader words like "a little bit," or "kind of," or "sort of."

Germany and the Netherlands, some Scandinavia, those are direct negative feedback cultures where they literally just say it bluntly and they can come across as harsh.

What's interesting about Asian culture that blew my mind was this omitting the bad and stating the good, and it's up to the listener to understand what was not great. If you're making a PowerPoint deck with 15 slides and your Asian coworker says, "Oh, I loved the first 10 slides." Okay, great. That means that the last five slides need work, but they're not going to explicitly state that to you.

Dave: Oh, interesting.

Emma: You know what else is really interesting? Real quick. This can help with problem-solving. If you ask a person from the United States of America to take a photo of someone. You have someone is sitting in a chair in a room. You say, "Okay, take a photo of them." Oftentimes, we will take just a headshot of the person. Someone from an Asian culture will take a photo of the entire room, so you get to see the person sitting in the chair with the whole context of the room.

You might notice in technical interviews, as an interviewer, that an American candidate solves problems or approaches problems much more differently than someone from an Asian culture where they're taught to view the whole versus a subset of the whole.

Dave: Yeah. When I was teaching English in Japan, I couldn't get around the fact, like, we'd be taking a test and they just let the kids talk to each other during the test. I just was like, "Can somebody kick these kids out? You have lost the reason for testing." But there is some wisdom there.

It was like, hey, in real life, they're never going to approach problems just by themselves. They're always going to have work colleagues in this small island society or this small town. So, they're always going to work things together with people, so maybe that's the best thing to do. Maybe that works. That's their style and we can write a note on their file and stuff like that and tailor their education for that. They may not be the most academically inclined child, but they're going to get through. They need to learn how to talk to people.

I just was like, "This changes my whole American--"

Emma: Yeah.

Dave: This changes my whole America.

Emma: It all goes back to the history of a culture. Asia has a long shared history, and so they are more collaborative in nature. It's much more of, like, you don't need to speak all the words to understand what someone is saying because they have that long history.

Versus the United States who had many different cultures moving there and you had to be the fastest. This move fast and break things is an American culture that really stemmed from the history of how this country came to be. This trickles into how we problem-solve and collaborate.

Dave: That's interesting.

Chris: It sure is.

00:34:36

Dave: I was just going to say one thing, too, just back to more technical interview stuff. I have this fear, what if my company I've worked for (for 14 years) disappears one day and then I have to get a job? But jargon is a big thing. I took some CSS classes in college, but I quit that because I just was like, "I hate this jargon stuff."

I have a friend who interviewed at Amazon. He showed me this interview question and it was like, "Given a dictionary of blah-blah-blah items, and then another dictionary of user-generated content," and I just was like, "Dude. This makes no sense."

But then I thought about the problem a little bit more and a little bit more and was like, "Oh, this is basically like, 'Given a list of top products, recommend a top product to this user who has bought whatever five similar products.'" It's just basically like, "You might also like," was the feature they were trying to describe.

Chris: Hmm.

Dave: I was like, "Oh, I know how to code that," but it was just like, how do you get around jargon, like these binary sort trees and link lists and all this stuff? I feel like a lot of self-taught developers have to pick this up on the fly, right?

Emma: Hmm.

Dave: We never--

Emma: Yeah. I think there is some jargon that you're just going to have to know, unfortunately. Like the names of data structures, or the names of algorithms, I don't see a way to necessarily get around that.

If you hear a word, a phrase, or something in the prompt of a question that you just don't understand, I think the best way to problem-solve that is to paraphrase the question back to the interviewer and make sure that you can sort out all the kinds in the question that you're not sure what they mean.

For example, first of all, as an interviewer, please don't ask your candidates, "What is the big O run time of this algorithm?" That's way too computer science-y.

But if you as a candidate get something like that, like, "Oh, what's the big O?" It's really good to know that big O relates to the efficiency of an algorithm as it pertains to performance and storage. But if you don't know, I think it's okay to ask, like, "Oh, can you maybe explain what this is?"

I think we should really stop expecting our candidates to know these things. A way to phrase that, you're still getting what you want to know out of this big O question without using that term. It's like, "Okay, can you evaluate? Explain to me why two nested for loops is less performant than two for loops sitting at the same level in this code. Why is one more performant than the other?"

Chris: Hmm.

Emma: That's a better way to ask a question than just throwing out all of these terms that you would expect candidates to know.

Chris: What's the bad way? Is that what big--? I don't even know what big O means.

Emma: Big O is like the upper bound on an algorithmic complexity. For example, if you have an array and you want to find the smallest element in the array, you could have two for loops where you've got to two different pointers and they compare every element against every other element. If you've got two nested for loops, this big O upper bound, the worst-case scenario is you have to check every element against every other element in that array.

Chris: Mm-hmm.

Emma: That would be big O of N squared because you have to run through it N times for the outer loop and N times for the inner loop, and you multiply those together. Yeah, it's confusing but it doesn't need to be. That's the thing.

Chris: I see. The real question is, okay, that's the worst you can do.

Emma: Mm-hmm.

Chris: How can you do better?

Emma: Exactly.

Chris: Yeah. Okay. That's cool. That's cool. That stuff is in the book, by the way. The book is very much not a wall of text of, "Read this advice." There's all kinds of code in this book, which I think is great. I think it could be like you took a boot camp and maybe you know some of this, but this might fill in the blanks with some things that you almost surely are going to need to know at some point. If you knew three of these, cool. Maybe that fourth one you didn't, and it's going to really save your butt.

What's some of the tech stuff in here that comes to mind the most or that you felt like was the most juicy when writing it?

00:38:43

Emma: Obviously, it's going to be data structures and algorithms. But that being said, as a Web developer, I actually really liked my chapter about HTML, CSS, JavaScript, accessibility. My goal with that was not to redo all of the resources that are out there to learn those technologies. It was really just to narrow down the set of skills that you're going to probably want to study for each of them and how to prioritize that because when I was studying for my Web domain interviews, it's like, "Holy crap! I have to memorize everything about every single language and technology that I'm working with." It's like, okay, how do we prioritize those for the ones you're most likely to see?

Chris: I think that's nice, too. I almost hope -- I'd love to be a fly on the wall of an interview where you're asked about big O and then you're asked about the button element.

Emma: Yeah.

Chris: I'd be like, "Hell, yeah. Good job."

Emma: That's a red flag. Don't work for that company.

[Laughter]

Chris: Well, I kind of meant it as, like, it'd be nice, if that was kind of -- maybe not. You wouldn't be kicked out the door for not knowing it but that you should use a button instead of a div or something.

Emma: Mm-hmm.

Chris: You know I don't care if you're a systems engineer. I hope the whole damn company knows that one.

Emma: Yeah.

00:39:54

Chris: I have some interviews this week. One of the things is I don't do this that often, so my skill level as an interviewer, I need to practice, too. One thing I know that we're not doing because their first interview is, I don't have a bunch of code. I'm not asking about a whole lot of code on round one. Is that common or not?

The thinking for us was that I want to kind of get to know you a little bit first, like, what do you do? Some philosophical stuff. Really, just a more informal chat. Big O is not going to come up in this first interview. That could change in the future if you think that's a mistake, or what.

The point is, I have no idea who you are. I think I'm going to learn more about you asking more casual questions than big O questions.

Emma: Yeah. Yeah, I agree. I mean there are plenty of ways to find out technical information about someone through a conversation. I remember I was asked in an interview, like, "How do you stay up to date in the industry?" or "How do you learn new skills?"

For me, it was like, "Oh, I love to read technical newsletters like CSS-Tricks and Frontend Focus and all those things." I like to read programming books, those kinds of things.

If someone says those types, like if they say that as their answer, then you know, okay, this person likes to learn. They like to stay up to date. It prevents you from having to check every single skill.

At the end of the day, we're hiring people. We're not hiring machines. Also, we program for humans. We don't program for machines. They're just kind of the interpreters. I think it's important to get to know people as people and not just as, can they problem-solve this insanely complex algorithmic question.

Chris: Yeah. yeah. You don't necessarily mind a non-technical first interview?

Emma: I think they're the best. I think that's how it should be done. It should be about the role, about the company, about the person, and what they're interested in learning. Why did they apply to your company?

Chris: Right.

Emma: What are they looking for to get out of this role? It's also good to see whether or not they talk crap about their current employer or their previous employers, right?

Chris: Hmm.

Emma: Learn about that. If you're listening to this, never talk shit about an employer. Let me tell you that right now. That's an immediate red flag to an interviewer.

There's a way to say that you need to move on to something else, like you're ready for a new challenge, you're like to explore a different company size, stuff like that. Don't talk crap about them.

Chris: Yeah. I guess for me it would be -- I don't know -- it depends on who they were and why. But it probably wouldn't look super good in a first talk because to me it would signal some degree of, like, negativity in general. Like if you went on a first date and all they did was complain about the food or something. You'd be like, so that you, right? You're the complainer, basically.

Emma: Yeah, or they just talk about their ex the whole time. [Laughter]

Chris: Yeah.

Dave: Yeah. You're like, this is -- well, okay.

Chris: Yeah. You're saying a little something about yourself that's kind of a bummer to me, in a way, because I certainly don't jive that way with people that are overly negative.

Emma: Yeah.

Chris: Okay. That's cool. Certainly, for us anyway, there is going to be technical stuff too.

Emma: Yeah.

Chris: But just later, just secondarily.

Dave: What's your experience like? I've heard of people on their third or sixth round of interviews.

Chris: Whoa.

00:43:22

Dave: The interview process seems to be getting longer.

Emma: Yeah.

Dave: Especially as you get more senior, maybe. What's your experience there? Is the hiring process broken or can it be better? What's your sense?

Emma: Yeah, I think it is broken in a lot of ways. But at the same time, how can we ensure that the people that we're hiring are able to be successful in the role? That's something that both parties should want to know.

As a candidate, do you want to be thrown into a role where you're going to be overwhelmed? I've been there and it is not fun for my mental health.

I think, yes, it is broken in many ways. But that being said, how can we actually ensure that someone will thrive? I think one thing Europe does really well is we have probation times of six months, which protects both the employer and the employee to say, "Hey. We're going to pay you. You're a full-time team member. But after six months, let's have a talk about if you're going to sign on permanently." You get evaluations from your team members halfway through, so you're very well aware where you can improve and if it's going well, and all of those things.

I think that's a much better system than having these massively drawn-out tests for candidates. Yeah, the process is long. Most of the interviews I've gone through, you have an initial recruiter call where you get to know the recruiter. You learn about the role.

The second is a coding test, whether that's asynchronous through an online portal that's timed or you have a remote interview, in person, or whatever. From there, it's typically the onsite, which is usually a half-day or all-day event where you go. Usually, would go.

Chris: Gees! Really?

Emma: Yeah, you would usually go onsite and have five hours of interviews, like two coding or two data structures -- data structures and algorithms, like a Web interview, systems design, hiring manager and process interview, and at that point then they would decide if they want to give you an offer.

Chris: Five hours?! I'm out....

Emma: Yeah, and often these are not paid. Many companies will actually fly candidates to their offices, which guess what, you have to take vacation time for. If you've got a family, you can't necessarily do that.

Chris: Yeah.

Emma: So -- [loud exhale]

Chris: You also have to kind of lie, don't you?

Emma: Yeah.

Chris: You have to be like, "I need to go somewhere for a reason."

Emma: Yeah.

Chris: [Laughter]

Dave: My uncle is getting married.

Chris: [Laughter] The old uncle is getting married.

Emma: Uh-huh.

Chris: That's a good one.

Dave: Yeah.

Chris: Oh, god. How was the wedding, Dave? The what?!

Emma: [Laughter]

Dave: Huh?!

Chris: Good. Really good. They had pizza. [Laughter]

Dave: Definitely not in San Francisco. That's for sure.

[Laughter]

Dave: Wow. Five hours of interviews. Is that just the worst or is that survivable?

00:46:09

Emma: That's pretty standard, but this is so sad to say. I guess the longer you're in the process -- the more interviews you've done, the more used to these things you become, which is super sad. That's the part that's broken, in my opinion.

There are things companies can do to make the process a little bit less broken. For example, one thing Spotify does is they have two interviewers. They have a lead and a shadow. We submit our feedback individually without talking to each other, so this helps prevent unconscious bias. That's one thing I think all companies should be doing.

You should also be having diverse interviewers to ensure that you're getting candidates from all different backgrounds and you're not just picking ones that look like you or have the same background as you. Yeah, as a whole, I would say the process is definitely broken. I honestly I wish I knew how to fix it.

Chris: Hmm.

Dave: I've had a few friends -- this is more in project management roles and stuff like that. One guy spent 40 hours putting together a PowerPoint presentation, like a fake PowerPoint. He delivers it. High-fives out the door, "Yeah, man! That was the best we've ever seen. Good job. Good job." Didn't get the job.

Emma: Mm-hmm.

Dave: It's just like, "What?!" Another friend--

Emma: That happened to me.

Dave: Another friend, he interviewed, and the feedback he got was, "You weren't energetic enough." I'm just like, "How?!" because it's a professional interview. You're supposed to be suit and tie, button-up shirt, blah-blah-blah. "Hey, yes, let's talk business." But did they want a youth minister coming in there like, "Hey, guys! Let's do balloon animals."

Emma: [Laughter]

Dave: That bothers me to such a degree. How do you--?

Emma: Right.

Dave: Should companies be upfront about this stuff? What tools do you have to be like, "Why did I not get that job?" and "Never do that to me again"?

Emma: Yeah. I think companies need to be straightforward. I did a take-home project. First of all, take-home projects, that's another area of the process that I totally forgot about that many companies will require you to spend time outside of work doing these projects, then submitting it, and then potentially presenting it.

I had this happen at IBM in Germany where I did that, and I gave the interview. They said -- or I presented it and they had no questions. They said, "This was the best presentation we've had, but we just don't have the money hire." I'm like, "What do you mean you don't have the money to hire?"

They were like, "We want to make you an offer. We just can't because we don't have the money." I'm like, "Why did you post the job in the first place?"

Chris: What?! [Laughter]

Dave: Now I'm double mad. Oh, my gosh.

Emma: I also interviewed at Hello Fresh. Their requirements did not say you needed to use a JavaScript framework, and so I just used vanilla JavaScript for the whole project. I spent hours on it. They basically asked me to redo their entire application, which is an ethical issue, first of all. Then my feedback was, "Oh, you should have used a framework or library." I'm like, "Okay. You've got to put that in your requirements then."

Dave: Yeah. Wow.

Chris: Hmm.

Dave: Hmm.

Chris: Do you think there's a lot of misfires? There must be of candidates that weren't hired that probably should have (for stupid reasons) or the other way around. Hires that were like, well, you nailed the bubble sort, so you're in, but we forgot to check if you were a dick or not.

Emma: Yeah! [Laughter] You can't change that, can you?

Chris: Yeah. [Laughter]

Dave: No. It takes a lot of therapy.

00:49:42

Chris: Oh, yeah. There must be. There must be. The bubble sort thing I always thought was kind of a joke. I would think of it in my mind as, like, if you're asked to do that in an interview -- people don't actually ask that, right? It's certainly in here and your book explains it tremendously well. I think if somebody bought this book and read that, you could probably -- if somebody threw you the "explain to me how the bubble sort works," you're able to answer that question. But is that real? Have you been asked to bubble sort something?

Emma: If they ask you that, run. No, I've been asked to sort a list of integers, for example. What's important there is to just pick a divide and conquer algorithm that's efficient, like merge sort or quicksort. You don't need to know all these sorting algorithms, to be honest. They're all just concepts, right? I think that when you start getting into the names and the code, it can be really intimidating.

Just remember the concepts, like how you pick. If you use quicksort, I think it's all about partition elements. You pick an element and then you recursively sort either side of the array and then merge them back together. You don't need to know every single sorting or searching algorithm. Just understand the most efficient one at a conceptual level, but you shouldn't be expected to necessarily write all of the code perfectly.

Chris: Yeah. Then if the answer -- because we all know how we actually do it, right? This is well past the point of a joke at this point. You Google it and you find the thing and then you do what it said in the thing. That's how you actually sort an array. Or you hope that the language that you're in already has a sorting algorithm and you just use it.

Emma: Mm-hmm.

Chris: But that's not the point, right? Theoretically, people asking you this aren't even -- isn't it more about learning how you think or whatever? Is that true?

Emma: It's supposed to be.

Chris: Yeah. [Laughter]

Emma: It's supposed to be, but sometimes it can turn into learning how much the interviewer is an egotistical maniac. If it's not done well -- as an interviewer, you should never be flexing your intelligence ever. It should be a conversation.

One of the things Spotify also does that I really enjoyed as a candidate was that they said, "This is a conversation. We don't expect you to memorize APIs, so if you need to look something up on your end or want us to look it up for you, we can do that." It's a collaborative session, and I loved that because I hate nothing more -- like, there's nothing worse that will throw you off your interview game than remembering the API for Slice or Spice and which one is it. I don't know.

Chris: Yeah.

Emma: [Laughter]

Chris: Does it--?

Dave: Gotcha! Got 'em!

Chris: Does it mutate the original array or not?

Dave: Oh!

Chris: Go try to remember that. Good luck.

Emma: Is it inclusive or exclusive with the indices? Who knows.

Chris: But let's just say you wanted to look at basically a comic-book explanation of how quicksort works. That's available to you for purchase at technicalinterviews.dev.

Dave: It's a really good book. It's over 200 pages of solid gold.

Emma: Aw!

Dave: You don't have to read it in sequential order. You could pick up the pieces you don't really -- or whatever. You could find the chapters you don't -- you don't have to read it in order, right?

Emma: No. Yeah.

Dave: I'm correct in that?

Emma: No, I use it -- I would use it as a reference and a checklist, especially for take-home projects. I promise, everyone listening, I didn't pay them to say such nice things. It sounds like I did, though. But thank you. [Laughter]

Chris: Is there anything else you want to say about that book, or yourself, or anything else you work on?

Emma: I think just the fact that this is an evergreen project, so it's going to be continuously updated and grown, especially from the interviewer side of things. We really plan to expand it there. If you buy it, you get lifetime updates, so don't feel like, "Oh, I bought the first edition. I'm not going to get any updates." No, you will.

We like to do purchase parity. Yeah, purchase parity. We like to keep it really affordable for people.

Chris: Is that the thing where if you're in a country where money goes less far, it's less expensive for you to buy it? Yeah, that's pretty cool. How does that work technically? Is it simple?

Emma: I don't know because I outsource this. I'm working with the Egghead IO team and Joel Hooks.

Chris: Ah!

Emma: They've saved my life. I mean they handle everything for me. I just produce the content and all of that stuff. They do the design and all of those things.

Chris: That's awesome.

Dave: Wonderful. Well, thank you so much, Emma, for coming on the show. For people who aren't following you and listening to your podcast and giving you money, how can they do that?

Emma: You can find all my shit posts on Twitter. I use the bird app daily. That's the best place to reach me.

Dave: All right. Well, perfect. All right. Thank you for coming on the show. This is really awesome.

Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month. Support us over on patreon.com/shoptalkshow and join the [techno voice] Discord.

Chris, do you have anything else you'd like to say?

Chris: ShopTalkShow.com.