ARTY: Hi, everyone. Welcome to Episode 260 of Greater Than Code. I am Arty Starr and I'm here with my fabulous co-host, Mandy Moore.

MANDY: Thank you, Arty. And I'm here with our guest today, Ian Douglas.

Ian has been in the tech industry for over 25 years and suggested we cue the Jurassic Park theme song for his introduction. Much of his career has been spent in early startups planning out architecture and helping everywhere and anywhere like a “Swiss army knife” engineer. He’s currently livestreaming twice a week around the topic of tech industry interview preparation, and loves being involved in developer education.

Welcome to the show, Ian.

IAN: Thanks for having me. It's great to be here.

MANDY: Awesome. So we like to start the show with our famous question: what is your superpower and how did you acquire it?

IAN: Probably curiosity. I've always been kind of a very curious mindset of wanting to know how things work. Even as a little kid, I would tear things apart just to see how something worked. My parents would be like, “Okay, great. Put it back together.” I'm like, “I don't know how to put it back together.” So [chuckles] they would come home and I would just have stuff disassembled all over the house and yeah, we threw a lot of stuff out that way. 

But it was just a curiosity of how things work around me and that led into computer programming, learning how computers worked and that just made the light bulb go off in my mind as a little kid of, I get to tell this computer how to do something, it's always going to do it. And that just led of course, into the tech industry where you sign up for a career in the tech industry, you’re signing up for lifelong learning and there's no shortage of trying to satiate that curiosity. I think it's just a never-ending journey, which is fantastic.

ARTY: When did you first discover computers? What was that experience like for you?

IAN: I was 8 years old. I think it was summer, or fall of 1982. I believe my dad came home with a Commodore 64. My dad was always kind of a gadget nut. Anything new and interesting on the market, he would find an excuse to buy and so he, brought home this Commodore 64 thinking family computer, but once he plunked it down in front of me, it sort of became mine. I didn't want to share. 

I grew up in Northern Canada way, way up in the Northwest territories and in the wintertime, we had two things to do. We could go play hockey, or we'd stay indoors and not freeze. So I spent a lot of time indoors when I wasn't playing hockey—played a lot of hockey as a kid. But when I was home, I was basically on this Commodore 64 all the time, playing games and learning how the computer itself worked and learning how the programming language of it worked.

Thankfully, the computer was something I had never took apart. Otherwise, it would have been a pile of junk, but just spending a lot of time just learning all the ins and outs. Back then, the idea was you could load the software and then you type a run command and it would actually execute the program. But if you type a list, it would actually show you all the source code of the program as well and that raised my curiosity, like what is all this symbols and what all these words mean? 

In the back of the Commodore 64 book, it had several chapters about the basic programming language. So I started picking apart all these games and trying to learn how they worked and then well, what would happen if I change this instruction to that and started learning how to sort of hack my games, usually break the game completely. But trying to hack it a little bit; what if I got like an extra ship, an extra level, or what if I change the health of my character, or something along those lines? And it kind of snowballed from there, honestly. It was just this fascination of, oh, cool, I get to look at this thing. I get to change it. I get to apply it. 

And then of course, back in the day, you would go to a bookstore and you'd have these magazines with just pages and pages and pages of source code and you'd go home and you type it all in expecting something really cool. At the end of it, you run it and it's something bland like, oh, you just made a spreadsheet application. It's like, “Oh, I wanted a game.” Like, “Shucks.”

[laughter] 

But as a little kid, that kind of thing wasn't very enticing, but I'm sure as an adult, it's like, oh cool, now I have a spreadsheet to track budgeting, or whatever at home. 

It was this whole notion of open source and just sharing knowledge and that really stuck with me, too and so, as I would try to satiate this innate curiosity in myself and learn something, I would go teach it to a friend and it's like, “Hey, hey, let me show you what I just did. I learned how to play this thing on the piano,” or “I learned how to sing this song,” or “I learned how to use a magnifying glass to cook an ant on the sidewalk.” 

[chuckles]

Whatever I learned, I always wanted to turn around and teach it to somebody else. I would get sometimes more excitement and joy out of watching somebody else do it because I taught them than the fact that I was able to learn that and do it myself. And so, after a while it was working on the computer became kind of a, oh yeah, okay, I can work on the computer, I can do the thing. But if I could turn around and show somebody else how to do that and then watch them explore and you watch that light bulb go off over their head, then it's like, oh, they're going to go do something cool with that. 

Just the anticipation of how are they going to go use that knowledge, that really stuck with me my whole life. In high school doing little bits of tutoring here and there. I was a paid tutor in college. Once I got out of college and got into the workplace, again, just learning on my own and then turning around and teaching others led into running my own web development business where I was teaching some friends how to do web development because I was taking on so much work that I had to subcontract it the somebody where I wasn't going to meet deadlines and so, I subcontracted them. That meant that I got to pay my friends to help me work this business. 

And so, that kind of kicked off and then I started learning well, how to servers work and how does the internet work and how do I run an email server on all this stuff? So just never-ending stream of knowledge going on in the internet and then just turning around and sharing that knowledge and keeping that community side of things building up over time.

MANDY: Very cool. So in your bio, it said you're streaming now so I'm guessing that's a big part of what you do today with the streaming. So what are you streaming?

IAN: So let's see, back in 2014, I started getting involved in mentorship with a local code school here in Denver called The Turing School of Software and Design. It's the 7-month code program and they were looking for someone that could help just mentor students. They were teaching Ruby on Rails at the time. So I got involved with them. I was working in Ruby at SendGrid at the time where I was working, who was later acquired by Twilio. And I'm like, “Yeah, I got some extra time. I can help some people out.” I like giving back and I like the idea of tutoring and teaching. 

I started that mentorship and it quickly turned into hey, do any of our mentors know anything about resumes and the hiring and interviewing and things like that. And by that point, I had been the lead engineer. I had done hiring. I hired several dozen engineers at SendGrid, or helped hire several dozen people at SendGrid. And I'm like, “Yeah, I've looked at hundreds and thousands of resumes.” Like, “What can I help with?” 

So I quickly became the career development guy to help them out and over time, the school started developing their career development curriculum and I like to think I had a hand in developing some of that. 3 years later, they're like, “You just want a job here? Like you're helping so many students, you just want to come on staff?” And so, I joined them as an instructor, taught the backend program, had a blast, did that for almost 4 full years. 

And then when I left Turing in June of 2021, I thought, “Well, I still want to be able to share this knowledge,” and so, I took all these notes that I had been writing and I basically put it all onto a website called techinterview.guide.

When I finished teaching, I'm like, “Well, I still miss sharing that knowledge with people,” and I thought, “How else can I get that knowledge out there in a way that is scalable and manageable by one human being?” And I thought, “Well, I'll just kind of see what other people are doing.” Fumbled around on YouTube, watched some YouTube videos, watched people doing livestreaming on LinkedIn, livestreaming on Facebook, livestreaming on YouTube and trying to think could I do that? Nah, I don't know if I could do that.

A friend of mine named Jonan Scheffler, he currently works at New Relic, he does a live stream. So I was hanging out on his stream one night and it was just so much fun seeing people interact and chat and how they engage the people in the chat and answering questions for them. I'm like, “I wonder if I could do that.” 

The curiosity took over from there and you can imagine where that went; went way down some rabbit holes on how to set up a streaming computer. Started streaming and found out that I wasn't very good at audio routing, [chuckles] recording things, and marketing, all that kind of stuff. But I kind of fumbled my way through it and Jonan was very generous with his time to help me straighten some things out and it kind of took off from there. So I thought, “Well, now I've got a platform where I can share this career development advice having been in the industry now for 25 years. Now, I've been director of engineering. I'm currently the director of engineering learning at a company. I've got an education background now as an instructor for several years. I've been doing tons of mentoring.”

I love to give back and I love to help other people learn a thing that's going to help improve their life. I think of it like a ripple effect, like I'm not going to go out and change the world, but I can change your world and that ripple effect is going to change somebody else's world and that's going to change somebody else's world. So that's how I see my part in all of this play out. I'm not looking to be the biggest name in anything. I'm just one person with a voice and I'm happy to share my ideas and my perspectives, but I'm also happy to have people on my stream that can share their ideas and perspectives as well. 

I think it's important to hear a lot of perspectives, especially when it comes to things like job hunt, interview prep, and how to build a resume. You're going to see so much conflicting advice out there like, “This is the way you should do it,” and someone else will be like, “No, this is the way you should do it.” Meanwhile, I'm on the sidelines going, “You can do it all of that way.” Just listen to everybody's advice and figure out how you want to build your resume and then that's your resume. It doesn't have to look like the way I want it, or the way that someone else wants it; it can look how you want it to look. This is just our advice kind of collectively. 

So the livestream took off from there and I've got only a couple of hundred followers, or so on Twitch, but it's been a lot of fun just engaging with chat and people are submitting questions to me all the time. So I do a lot of Q&A sessions, like ask me anything sessions and it's just been a ton of fun.

ARTY: That's awesome. I love the idea of focusing on one person and how you can make a difference in that one person's life and how those differences can ripple outward. That one-on-one connection, I feel like if we try and just broadcast and forget about the individuals, it's easy for the message and stuff to just get lost in ether waves and not actually make that connection with one person. Ultimately, it's all those ones that add up to the many.

IAN: Definitely. Yeah.

ARTY: So can you tell us a little bit more about the Tech Interview Guide and what your philosophy is regarding tech interviews?

IAN: The tech interview process in – well, I mean, just the interview process in general in the tech industry is pretty broken. It lends itself very well to people who come from position and privilege that they can afford expensive universities and have oodles and oodles of free time to go study algorithms for months and months and months to go jump through a whole bunch of hoops for companies that want four, or five, six rounds of interviews to try to determine whether you're the right fit for the company and it's super broken. 

There are a lot of companies out there that are trying to change things a little bit and I applaud them. It's going to be a tough journey, for sure. Trying to convince companies like hey, this is not working out well for us as candidates trying to apply for jobs. 

As a company, though I understand because I've been a hiring manager that you need to be able to trust the people that you're hiring. You need to trust that they can actually do the job. Unfortunately, a lot of the tech interview process does not adequately mimic what the day-to-day responsibility of that job is going to be. 

So the whole philosophy of me doing the Tech Interview Guide is just an education of, “Hey, here's my perspective on what you're likely to face as a technical interview. These are the different stages that you'll typically see.” I have a lot of notes on there about how to build a resume, how to build a cover letter, thoughts on building a really big resume and then how to trim it down to one page to go apply for a particular job. How to write a cover letter that's customized to the business to really position yourself as the best candidate for that role. And then some chapters that I have yet to write are going to be things like how do you negotiate once you get an offer, like what are some negotiation tips. 

I've shared some of them live on the stream and I've shared a growing amount of information as I learn from other people as well, then I'll turn around and I'll share that on the stream. The content that's actually on the website right now is probably 3, 4 years old, some of it at least and so, I'm constantly going back in and I'm trying to revamp that material a little bit to kind of be as modern as possible. 

I used to want to go a self-publish route where I actually made a book. Several of my friends have actually gone through the process of actually making a book and getting it published. I'm like, “Oh, I want to do that, too. My friends are doing that. I could do that, too,” and I got looking into it. It's like, okay, it's an expensive, really time-consuming process and by the time I get that book on a shelf somewhere, a lot of the information is going to be out of date because a lot of things in the tech industry change all the time. So I decided I would just self-publish an online book where I can just go in and I can just constantly refresh the information and people can go find whatever my current perspective is by going to the website. 

And then as part of the website, I also have a daily email series that people can sign up for. I'm about to split it into four mailing lists. But right now, it's a single mailing list where I'm presenting technical questions and behavioral questions that you're likely to get asked as a web developer getting into the business. But I don't spend time in the email telling you how to answer the question; what I do instead is I share from the interviewer's perspective. This is why I'm asking you this question. This is what I hope to hear. This is what's important for me to hear in your answer. 

Because there's so many resources out there already that are trying to tell you how to craft the perfect answer, where I'm trying to explain this is why this question is important to us in the first place. So I'm taking a little bit different perspective on how I present that information and to date I've sent out, I don't know, something like 80,000 emails over a couple of years to folks that have signed up for that, which has been really tremendous to see. I get a lot of good feedback from that. But again, that information it doesn't always age well and interview processes change. 

I'm actually going through the process right now in the month of November to rewrite a lot of that information, but then also break out into multiple lists and so, where right now it's kind of a combination of a little bit of technical questions, a little bit of behavioral questions, a little bit of procedural, like what is an interview and so on. Now I'm actually going to break them out into separate lists of this list is all just technical questions and this list is all just behavioral questions and this list is going to be general process and then the process of going through the interview and how to do research and so on. And then the last one is just general questions and answers and a lot of that is stemmed from the questions that people have submitted to me that I answered on the live stream. So it all kind of packages up together.

MANDY: That's really cool. I'd like to get into some of the meat of the material that you're putting out here. 

IAN: Yeah.

MANDY: So as far as what are some of the biggest questions that you get on your street?

IAN: Probably the most popular question I get—because a lot of the people that come by the stream and find the daily email list are new in the industry and they're trying to find that first job. And so by far, the number one question is, how do I even get a job in the industry right now? I have no experience. I've got some amount of education, whether it's an actual CS degree, or something similar to a CS degree, or they've gone through a bootcamp of some kind. How do I even get that first job? How do I position myself? How do I differentiate myself? How do I even get a phone call from a company? 

That's a lot of what's broken in the industry. Everybody in the industry right now wants people with experience, or they're saying like, “Oh, this is a “entry-level role,” but you must have 3 to 4 years’ experience.” It's like, well, it's not entry level if you're asking for experience; it can't be both. All they're really doing is they're calling it an entry-level role so they don't have to pay you as much. But if they want 3-, or 4-years’ experience, then you should be paying somebody who has 3-, or 4-years’ experience. 

So the people writing these job posts are off their rocker a little bit, but that's by far, the number one question I get is how do I even get that first job. Once you get that first job and you get a year, year and a half, 2 years’ experience, it's much easier to get that second job, or third job. It's not like oh, I'm going to quit my job today and have a new job tomorrow. But the time to get that next job is usually much, much shorter than getting this first job. 

I know people that have gone months and months, or nearly a year just constantly trying to apply, getting ghosted, like not getting any contact whatsoever from companies where they're sending in resumes and trying to apply for these jobs. Again, it's just a big indication of what's really broken in our industry that I think could be improved. I think that there's a lot of room for improvement there.

MANDY: So what do you tell them? What's your answer for that? How do they get their first job? How do you get your first job?

IAN: That's a [chuckles] good question. And I hate to fall back on the it depends answer. It really does depend on the kind of career that you want to have. I tell people often in my coaching that the tech industry is really a choose your own adventure kind of book. Like, once you get that job a little bit better, what you want your next job to be and so, you get to choose. If you get your first job as a QA developer, or you get that first job as a technical writer, or you get that first job doing software development, or you get that first job in dev ops and then decide, you don't want to do that anymore, that's fine. 

You can position yourself to go get a job doing some other kind of technical job that doesn't have to be what your previous job was. Now, once you have that experience, though recruiters are going to be calling you and saying, “Hey, you had a QA role. I've also got a QA role,” and you just have to stand firm and say, “No, that's not the direction I'm taking my career anymore. I want to head in this direction. So I'm going to apply for a company where they're looking for people with that kind of direction.” 

It really comes down to how do you show the company what you bring to the company and how you're going to make the company better, how are you going to make the team better, what skill, experience, and background are you bringing to that job. A lot of people, when they apply for the job, they talk about what they don't have. Like, “Oh, I'm an entry level developer,” or “I only went to a bootcamp,” or “I don't know very much about some aspect of development like I don't know, test driven development,” or “I don't really understand object-oriented programming,” or “I don't know anything about Docker, but I want to apply for this job.” Well, now you're highlighting what you don't have and to get that first job, you have to highlight what you do have.

So I often tell people on your resume, on your LinkedIn, don't call yourself a junior developer. Don't call yourself an entry level. Don't say you're aspiring to be. You are. You are a developer. If you have studied software development, you can write software, you're a software developer. Make that your own title and let the company figure out what level you are. So just call yourself a developer and start applying for those jobs. 

The other advice that I tend to give people is you don't have to feel like you meet a 100% of the requirements in any job posts. As a hiring manager, when I read those job posts often, it's like, this is my birthday wish list. I hope I can find this mythical unicorn that has all of these traits [laughter] and skills and characteristics and that person doesn't exist. In fact, if I ever got a resume where they claim to have all that stuff, I would immediately probably throw the resume in the bin because they're probably lying, because either they have all those skills and they're about to hit me up for double the salary, or they're just straight up lying that they really don't have all those skills. 

As a hiring manager, those are things that we have to discern over time as we're evaluating people and talking with them and so on. But I would say if you meet like 30 to 40% of those skills, you could probably still apply. 

The challenge then is when you get that phone call, how do you convince them that you're worth taking a shot, that you're worth them taking the risk of hiring you, helping train you up in the skills that you don't have. But on those calls, you still need to present this is what I do bring to the company. I'm bringing energy, I’m bringing passion, and I'm bringing other experience and background and perspectives on things, hopefully from – just increasing the diversity in tech, just as an example. You're coming from a background, or a walk of life that maybe we don't currently have on the team and that's great for us and great for our team because you're going to open our eyes to things that we might not have thought of. 

So I think apply anyway. If they're asking for a couple of years’ experience and you don't have it, apply anyway. If they're asking for programming languages you don't know, apply anyway. The languages you do know, a lot of that skill is going to transfer into a new language anyway. And I think a lot of companies are really missing out on the malleability and how they can shape an entry-level developer into the kind of developer and kind of engineer that they want to have on the team. 

Now you use that person as an example and say, “Now we've trained them with the process that we want, with the language and the tools that we want. They know the company goals.” We've trained them. We've built them up. We've invested in them and now everybody else we hire, we're going to hold to that standard and say, “If we're going to hire from outside, this is what we want,” and if we hire someone who doesn't have that level of skill, we're going to bring them up to that skill. I think a lot of companies are missing out on that whole aspect of hiring, that is they can take a chance on somebody who's got the people skills and the collaboration skills and that background and the experiences of life and not necessarily the technical skills and just train them on the technical skills.

I went on a rant on this on LinkedIn the other day, where I was saying the return on investment. If a company is spending months and months and months trying to hire somebody, that's expensive. You're paying a recruiter, you're paying engineers, you're paying managers to screen all these people, interview all these people, and you're not quite finding that 100% skill match. Well, what if you just hired somebody months ago, spend $5,000 training them on the skills they didn't have, and now you're months ahead of the game. You could have saved yourself so much money so much time. You would have had an engineer on the team now. And I think a lot of companies are kind of missing that point. Sorry, I know I get very soapbox-y on some of the stuff.

ARTY: I think it's important just highlighting these dynamics and stuff that are broken in our industry and all of the hoops and challenges that come with trying to get a job. 

You mentioned a couple of things on the other side of one, is that the interview processes themselves don't align to what it is we actually need skill-wise day-to-day. What are the things that you think are driving the creation of interviews that don't align with the day-to-day stuff? Like what factors are bringing those things so far out of alignment?

IAN: That's a great question. I would say I have my suspicions. So don't take this as gospel truth, but from my own perspective, this is what I think. The big, big tech companies out there, like the big FAANG companies, they have a very specific target in mind of the kind of engineers that they want on their team. They have studied very deep data structures and algorithms, the systems thinking and the system design, and all this stuff. Like, they've got that knowledge, they've got that background because those big companies need that level of knowledge for things like scaling to billions of users, highly performant, and resilient systems. 

Where the typical startup and typical small and mid-sized company, they don't typically need that. But those kinds of companies look at FAANG companies and go, “We want to be like them. Therefore, we must interview like them and we must ask the same questions that they ask.” I think this has this cascading effect where when FAANG companies do interviews in a particular way, we see that again, with this ripple effect idea and we see that ripple down in the industry. 

Back in the early 2000s, mid 2000s—well, I guess right around the time when Google was getting started—they were asking a lot of really oddball kinds of questions. Like how many golf balls fit in a school bus and those were their interview challenges. It's like, how do you actually go through the calculation of how many golf balls would fit in a school bus and after a while, I think by 2009, they published an article saying, “Yeah, we're going to stop asking those questions. We weren't getting good signals. Everybody's breaking down those problems the same way and it wasn't really helpful.” 

Well, leading up to that point, everyone else was like, “Oh, those are cool questions. We're going to ask those questions, too,” and then when Google published that paper, everyone else was like, “Yeah, those questions are dumb. We're not going to ask those questions either.” And then they started getting into what we now see as like the LeetCode, HackerRank type of technical challenges being asked within interviews. I think that there's a time and place for some of that, but I think that the types of challenges that they're asking candidates to do should still be aligned with what the company does.

One criticism that I've got. For example, I was looking at a technical challenge from one particular company that they asked this one particular problem and it was using a data structure called Heap. It was, find a quantity of location points closest to a target. So you're given a list of latitude, longitude values, and you have to find the five latitude and longitude points that are closest to a target. It's like, okay and so, I'm thinking through the challenge, how would I solve that if I had to solve it? 

But then I got thinking that company has nothing to do with latitude and longitude. That company has nothing to do with geospatial work of any kind. Why are they even asking that problem? Like, it's so completely misaligned that anybody they interview, that's the first thing that's going to go through their mind as a candidate is like, “Why are they asking me this kind of question?” Like, “This has nothing to do with the job. It had nothing to do with the role. I don't study global positioning and things like that. I know what latitude and longitude are, but I've never done any kind of math to try to figure out what those things would be and how you would detect differences between them.” Like, I could kind of guess with simple math, but unless you've studied that stuff, it's not going to be this, “Oh yeah, sure, no problem. It's this formula, whatever.” 

We shouldn't have to expect that candidates coming to a business are going to have that a, formula memorized, especially when that's not what your company does. And a lot of companies are like, “Oh, we're got to interview somebody. Quick, go to LeetCode and find a problem to ask them.” All you're going to do is you're going to bias your interview process towards people that have studied those problems on LeetCode and you're not actually going to find people that can actually solve your day-to-day challenges that your company is actually facing.

ARTY: And instead, you're selecting for people that are really good at things that you don't even need. [chuckles] It's like, all right! It totally skews who you end up hiring toward people that aren't even necessarily competent in the skills that they actually need day-to-day. Like you mentioned FAANG companies need these particular skills. I don't even think that for resilience, to be able to build these sort of systems, and even on super hardcore systems, it's very seldom that you end up writing algorithmic type code. Usually, most of the things that you deal with in scaling and working with other humans and stuff, it's a function of design and being able to organize things in conceptual ways that make sense so that you can deconstruct a complex, fuzzy problem into little pieces that make sense and can fit together like a jigsaw puzzle.

I have a very visual geometric way of thinking, which I find actually is a core ability that makes me good at code because I can imagine it visually laid out and think about the dependencies between things as like tensors between geographically located little code bubbles, if you will.

IAN: Sure.

ARTY: Being able to think that way, it’s fundamentally different than solving algorithm stuff. But that deconstruction capability of just problem breakdown, being able to break down problems, being able to organize things in ways that make sense, being able to communicate those concepts and come up with abstractions that are easy enough for other people on your team to understand, ideally, those are the kinds of engineers we want on the teams. Our interview processes ought to select for those day-to-day skills of things that are the common bread and butter. [chuckles] 

IAN: I agree.

ARTY: What we need to succeed on a day-to-day basis.

IAN: Yeah. We need the people skills more than we need the hard technical skills sometimes. I think if our interview process could somehow tap into that and focus more on how do you collaborate, how do you do code reviews, how do you evaluate someone else's code for quality, how do you make the tradeoff between readability and optimization—because those are typically very polarized, opposite ends of the scale—how do you function on a team, or do you prefer to go heads down and just kind of be by yourself and just tackle tasks on your own? I believe that there's a time and place for that, too and there are personality types where you prefer to go heads down and just have peace and quiet and just get your work done and there's nothing wrong with that. 

But I think if we can somehow tap into the collaborative process as part of the interview, I think it's going to open a lot of companies up to like, “Oh, this person's actually going to be a really great team member. They don't quite have this level of knowledge in database systems that we hope they'd have, but that's fine. We'll just send them on this one-week database training class that happens in a week, or two and now they'll be trained.” [overtalk]

MANDY: Do they want to learn?

IAN: Right. Do they want to learn? Are they eager to learn? Because if they don't want to learn, then that's a whole other thing, too. But again, that's something that you can screen for. Like, “Tell me what you're learning on the side, or “What kinds of concepts do you want to learn?” Or “In this role, we need you to learn this thing. Is that even of interest to you?” Of course, everyone's going to lie and say, “Yeah,” because they want the paycheck. But I think you can still narrow it down a little bit more what area of training does this person need. So we can just hire good people on the team and now our team is full of good people and collaborative, team-based folks that are willing to work together to solve problems together and then worry about the technical skills as a secondary thing.

MANDY: Yeah. I firmly believe anybody can learn anything, if they want to. I mean, that's how I've gotten here.

IAN: Yeah, for sure. Same with me. I'm mostly self-taught. I studied computer engineering in college, so I can tell you how all the little microchips in your computer work. I did that for the first 4 years of my career and then I threw all that out the window and I taught myself web development and taught myself how the internet works. 

And then every job I had, that innate curiosity in me is like, “Oh, I wonder how e-commerce works.” Well, I went and got an e-commerce job, it's like, okay, well now I wonder how education works and I got into the education sector. Now, I wonder how you know this, or that works and so, I got into financial systems and I got into whatever and it just kind of blew my mind. I was like, “Wow, this is how all these things kind of talk to each other,” and that for me was just fascinating, and then turning around and sharing that knowledge with other people. 

But some people are just very fixed mindset and they want to learn one thing, they want to do that thing, and that's all they know. But I think, like we kind of talked about early in the podcast, you sign up for a career in this industry and you’re signing up for lifelong learning. There's no shortage to things that you can go learn, but you have to be willing to do it.

MID-ROLL: Rarely does a day pass where a ransomware attack, data breach, or state sponsored espionage hits the news. It's hard to keep up with all this and also to know if you’re protected. Don't worry, Kaspersky’s got you covered. Each week their team looks at the latest news, stories, and topics you might have missed during the week on the Transatlantic Cable Podcast. Mixing in-depth discussion, expert guests from around the world, a pinch of humor, and all with an easy to consume style - be sure you check them out today.

ARTY: What kind of things could we do to potentially influence the way hiring is done and these practices with unicorn skilled searches and just the dysfunctional aspects on the hiring side? Because you're teaching all these tech interview skills for what to expect in the system and how to navigate that and succeed, even though it's broken. But what can we do to influence the broken itself and help improve these things?

IAN: That's a great question. Breaking it from the inside out is a good start. I think if we can collectively get enough people together within these, especially the bigger companies and say like, “Hey, collectively, as an industry, we need to do interviewing differently.” And then again, see that ripple effect of oh, well, the FAANG companies are doing it that way so we're going to do it that way, too. 

But I don't think that's going to be a fast change by any stretch. I think there are always going to be some types of roles where you do have to have a very dedicated, very deep knowledge of system internals and how to optimize things, and pure algorithmic types of thinking. I think those kinds of jobs are always going to be out there and so, there's no fully getting away from something like a LeetCode challenge style interview.

But I think that for a lot of small, mid-sized, even some large-sized companies, they don't have to do interviewing that way. But I think we can all stand on our soapbox and yell and scream, “Do it differently, do it differently,” and it's not going to make any impact at all because those companies are watching other companies for how they're doing it. 

So I think gradually, over time, we can just start to do things differently within our own company. And I think for example, if the company that I was working at, if we completely overhauled our interview process that even if we don't hire somebody, if someone can walk away from that going, “Wow, that was a cool interview experience. I’ve got to tell my friends about this.” 

That's the experience that we want when you walk away from the company if we don't end up hiring. If we hire you, it's great. But even if we don't hire you, I want to make sure that you've still got a really cool interview experience that you enjoyed the process, that it didn't just feel like another, “Okay, well, I could have just grind on LeetCode for three months to get through that interview.” I don't ever want my interviews to feel like that. 

So I think as more of us come to this understanding of it's okay to do it differently and then collectively start talking about how could we do it differently—and there are companies out there that are doing it differently, by the way. I'm not saying everyone in the industry is doing all these LeetCode style interviews. There are definitely companies out there that are doing things differently and I applaud them for doing that.

And I think as awful as it was to have the pandemic shut everything down to early 2020, where no hiring happened, or not a lot of hiring happened over the summer, it did give a lot of companies pause and go, “Well, hey, since we're not hiring, since we got nobody in the backlog, let's examine this whole interview process and let's see if this is really what we want as a company.” And some companies did. They took the time, they took several months and they were like, “You know what, let's burn this whole thing down and start over” as far as their interview process goes. Some of them completely reinvented what their interview process was and turned it into a really great process for candidates to go through. So even if they don't get the job, they still walk away going, “Wow, that was neat.”

I think if enough of us start doing that to where candidates then can say, “You know what, I would really prefer not to go through five, or six rounds of interviews” because that's tiring and knowing that what you're kind of what you're in for, with all the LeetCode problems and panel after panel after panel. Like, nobody wants to sit through that. 

I think if enough candidates stand up for themselves and say, “You know what, I'm looking for a company that has an easier process. So I'm not even going to bother applying.” I think there are enough companies out there that are desperately trying to hire that if they start getting the feedback of like you know what, people don't want to interview with us because our process is lousy. They're going to change the process, but it's going to take time. 

Unfortunately, it's going to drag out because companies can be stubborn and candidates are also going to be stubborn and it's not going to change quickly. But I think as companies take the step to change their process and enough candidates also step up to say, “Nah, you know what, I was going to apply there,” or “Maybe I got through the first couple of rounds, but you're telling me there's like three more rounds to go through? Nah, I'm not going to bother.” 

Companies are now starting to see candidates ghost them and walk away from the interview process because they just don't want to be bothered. I think that's a good signal for a company to take a step back and go, “Okay, we need to change our process to make it better so the people do want to apply and enjoy that interview process as they come through.” But it's going to take a while to get there.

ARTY: Makes me think about we were talking early on about open source and the power of open source. I wonder with this particular challenge, if you set up a open source hiring manifesto, perhaps of we're going to collaborate on figuring out how to make hiring better. Well, what does that mean? What is it we're aiming for? We took some time to actually clarify these are the things we ought to be aiming for with our hiring process and those are hard problems to figure out. How do we create this alignment between what it is we need to be able to do to be successful day-to-day versus what it is we're selecting for with our interview process? Those things are totally out of whack. 

I think we're at a point, at least in our industry, where it's generally accepted that how we do interviewing and hiring in these broken things—I think it’s generally accepted that it's broken—so that perhaps it's actually a good opportunity right now to start an initiative like that, where we can start collaborating and putting our knowledge together on how we ought to go about doing things better. Even just by starting something, building a community around it, getting some companies together that are working on trying to improve their own hiring processes and learning together and willing to share their knowledge about things that are working better, such that everybody in the industry ultimately benefits from us getting better at these kinds of things. As you said, being able to have an interview process that even if you don't get the job, it's not a miserable experience for everyone involved. [chuckles] Like there's no reason for that.

IAN: Yeah.

MANDY: That's how we – I mean, what you just explained, Arty isn't that how we got code of conducts? Everybody's sitting down and being like, “Okay, this is broken. Conferences are broken. What are we going to all do together?” So now why don't we just do the same thing? I really like that idea of starting an open source initiative on interviewing. Like have these big FAANG companies be like, “I had a really great interview with such and such company.” Well, then it all spirals from there. I think that's super, super exciting.

ARTY: Yeah. And what is it that made this experience great? You could just have people analyze their interview experiences that they did have, describe well, what are the things that made this great, that made this work and likewise, you could collect anti-patterns. Some of the things that you talked about of like, are we interviewing for geolocation skills when that actually has absolutely nothing to do with our business? We could collect these things as these funky anti-patterns of things so that people could recognize those things easier in there because it's always hard to see yourself. It's hard to see yourself swinging.

IAN: An interesting idea along those lines is what if companies said like, “Hey, we want the community to help us fix our interview process. This is who we are, this is what our business does. What kinds of questions do you think we should be asking?” And I think that the community would definitely rally behind that and go, “Oh, well, you're an e-commerce platform so you should be asking people about shopping cart implementations and data security around credit cards and have the interview process be about what the company actually does.” 

I think that that would be an interesting thing to ask the community like, “What do you think we should be asking in these interviews?” Not that you're going to turn around and go, “Okay, that's exactly what we're going to do,” but I think it'll give a lot of companies ideas on yeah, okay, maybe we could do a take-home assignment where you build a little shopping cart and you submit that to us. We'll evaluate how you did, or what you changed, or we're going to give you some code to start with and we're going to ask you to fix a bug in it, or something like, I think that there's a bigger movement now, especially here in Canada, in the US of doing take-home assignments. 

But I think at the same time, there are pros and cons of doing take-home assignments versus the on-site technical challenges. But what if we gave the candidate a choice as part of that interview process, too and say, “Hey, cool. We want to interview you. Let's get through the phone screen and now that you've done the phone screen, we want to give you the option of, do you want to do a small take-home assignment and then do a couple of on-site technical challenges? Do you want to do a larger take-home and maybe fewer on-site technical challenges?” 

I think there's always going to be some level of “Okay, we need to see you code in front of us to really make sure that you're the one that wrote that code.” I got burned on that back in 2012 where I thought somebody wrote some code and they didn't. They had a friend write it as their take-home assignment and so, I brought them in for the interview and I'm like, “Cool, I want you to fix this bug,” and they had no idea what to do. They hadn’t even looked at the code that their friend wrote for them it's like, why would you do that? 

So I think that there's always going to be some amount of risk and trust that needs to take place between the candidates and the companies. But then on the flip side of that, if it doesn't work out, I really wish companies would be better about giving feedback to people instead of just ghosting them, or like, “Oh, you didn't and pass that round. So we're just not even going to call you back and tell you no. We're just not ever just going to call.” The whole ghosting thing is, by far, the number one complaint in the tech industry right now is like, “I applied and I didn't even get a thanks for your resume. I got nothing,” or maybe you get some automated reply going, “We'll keep you in mind if you're a match for something.” 

But again, those apple looking at tracking systems are biased because the developers building them and the people reading the resumes are going to have their own inherent bias in the search terms and the things that they're looking for and so on. So there's bias all over the place that's going to be really hard to get rid of. But I think if companies were to take a first step and say like, “Okay, we're going to talk to the community about what they would like to see the interview process be,” and start having more of those conversations. 

And then I think as we see companies step up and make those changes, those are going to be the kinds of companies where people are going to rally behind them and go, “I really want to work there because that interview process is pretty cool.” And that means the company is – well, it doesn't guarantee the company's going to be cool, but it shows that they care about the people that are going to work there. 

If people know that the company is going to care about you as an employee, you're far more likely to want to work there. You're far more likely to be loyal and stay there for a long term as opposed to like oh, I just need to collect a paycheck for a year to get a little bit of experience and then job hop and go get a better title, better pay. So I think it can come down to company loyalty and stuff, too.

MANDY: Yeah. Word of mouth travels fast in this industry. 

IAN: Absolutely. 

MANDY: And to bring up the code of conduct thing and now people are saying, “If straight up this conference doesn't have a code of conduct, I'm not going.”

IAN: Yeah. I agree. It'll be interesting to see how something like this tech interview overhaul open source idea could pick up momentum and what kinds of companies would get behind it and go, “Hey, we think our interview process is pretty good already, but we're still going to be a part of this and watch other companies step up to.” 

When I talked earlier about that ripple effect where Google, for example, stopped asking how many golf balls fit in a school bus kind of thing and everyone else is like, “Yeah, those questions are dumb.” We actually saw this summer, Facebook and Amazon publicly say, “We're no longer going to ask dynamic programming problems in our interviews.” It's going to be interesting to see how long that takes to ripple out into the industry and go, “Yeah, we're not going to ask DP problems either,” because again, people want to be those big companies. They want to be billion- and trillion-dollar companies, too and so, they think they have to do everything the same way and that's not always the case.

But there's also something broken in the system, too with hiring. It's not just the interview process itself, but it's also just the lack of training. I've been guilty of this myself, where I've got an interview with somebody and I've got back-to-back meetings. So I just pull someone on my team and be like, “Hey, Arty, can you come interview this person?” And you're like, “I've never interviewed before. I guess, I'll go to LeetCode and find a problem to give them.” You're walking in there just as nervous as the candidate is and you're just throwing some technical challenge at them, or you're giving them the technical challenge that you've done most recently, because you know the answer to it and you’re like, “Okay, well, I guess they did all right on it. They passed,” or “I think they didn't do well.” 

But then companies aren't giving that feedback to people either. There's this thinking in the industry of oh, if we give them feedback, they're going to sue us and they're going to say it's discriminatory and they're going to sue us. Aline Lerner from interviewing.io did some research with her team and literally nobody in recent memory has been sued for giving feedback to candidates. 

If anything, I think that it would build trust between companies and the candidates to say, “Hey, this is what you did. Well, this is what we thought you did okay on. We weren't happy with the performance of the code that you wrote so we're not moving forward,” and now you know exactly what to go improve. 

I was talking to somebody who was interviewing at Amazon lately and they said, “Yeah, the recruiter at Amazon said that I would go through all these steps,” and they had like five, or six interviews, or something to go through. And they're like, “Yeah, and they told me at the end of it, we're not going to give you any feedback, but we will give you a yes, or no.” 

It's like so if I get a no, I don't even find out what I didn't do well. I don't know anything about how to improve to want to go apply there in the future. You're just going to tell me no and not tell me why? Why would I want to reapply there in the future if you're not going to tell me how I'm going to get better? I'm just going to do the same thing again and again. I'm going to be that little toy that just bangs into the wall and doesn't learn to steer away from the wall and go in a different direction. If you're not going to give me any feedback, I'm just going to keep banging my head against this wall of trying to apply for a job and you're not telling me why I'm not getting it. It's not helpful to the candidate and that's not helpful to the industry either. It starts affecting mental health and it starts affecting other things and I think it erodes a lot of trust between companies and candidates as well.

ARTY: Yeah. The experience of just going through trying to get a job and going through the rejection, it's an emotional experience, an emotionally challenging experience. Of all things that affect our feels a lot, it's like that feeling of social rejection. So being able to have just healthier relationships and figuring out how to see another person as a human, help figure out how you can help guide and support them continuing on their journey so that the experience of the interview doesn't hurt so much even when the relationship doesn't work out, if we could get better at those kinds of things. There's all these things that if we got better at, it would help everybody.

IAN: I agree. 

ARTY: And I think that's why a open source initiative kind of thing maybe make sense because this is one of those areas that if we got better at this as an industry, it would help everybody. It's worth putting time in to learn and figure out how we can do better and if we all get better at it and stuff, there's just so many benefits and stuff from getting better at doing this. 

Another thing I was thinking about. You were mentioning the language thing of how easy it is to map skills that we learned from one language over to another language, such that even if you don't know the language that they're coding in at a particular job, you should apply anyway. [chuckles] I wonder if we had some data around how long it takes somebody to ramp up on a new language when they already know similar-ish languages. If we had data points on those sort of things that we’re like, “Okay, well, how long did it actually take you?” Because of the absence of that information, people just assume well, the only way we can move forward is if we have the unicorn skills. 

Maybe if it became common knowledge, that it really only takes say, a couple months to become relatively proficient so that you can be productive on the team in another language that you've never worked in before. Maybe if that was a common knowledge thing, that people wouldn't worry about it so much, that you wouldn't see these unicorn recruiting efforts and stuff. People would be more inclined to look for more multipurpose general software engineering kinds of skills that map to whatever language that you're are doing. That people will feel more comfortable applying to jobs and going, “Oh, cool. I get the opportunity to learn a new language! So I know that I may be struggling a bit for a couple months with this, but I know I'll get it and then I can feel confident knowing that it's okay to learn my way through those things.” 

I feel if maybe we just started collecting some data points around ramp up time on those kind of things, put a database together to collect people's experiences around certain kind of things, that maybe those kinds of things would help everyone to just make better decisions that weren't so goofy and out of alignment with reality.

IAN: Yeah, and there are lots of cheat sheets out there like, I'm trying to remember the name of it. I used to have it bookmarked. But you could literally pull up two programming languages side by side in the same browser window and see oh, if this is how you do it in JavaScript, this is how you do it on Python, or if this is how you write this code in C++, here's how you do it in Java. It gives you a one-to-one correlation for dozens, or hundreds of different kinds of blocks of code. That's really all you need to get started and like you said, it will take time to come proficient to where you don't have to have that thing up on your screen all the time. 

But at the same time, I think the company could invest and say, “You know what, take a week and just pour everything you’ve got into learning C Sharp because that's the skill we want you to have for this job.” It's like, okay, if you are telling me you trust me and you're making me the job offer and you're going to pay me this salary and I get to work in tech, but I don't happen to have that skill, but you're willing to me in that skill, why would I not take that job? You're going to help me learn and grow. You're offering me that job with a salary. Those are all great signals to send. 

Again, I think that a lot of companies are missing out and they're like, “No, we're not going to hire that person. We're just going to hold out until we find the next person that's a little bit better.” I think that that's where some things really drop off in the process, for sure is companies hold out too long and next thing they know, months have gone by and they've wasted tons of money when they could have just hired somebody a long time ago and just trained them.

I think the idea of an open source collective on something like this is pretty interesting. At the same time, it would be a little subjective on “how quickly could someone ramp up on a, or onboard on a particular technology.” Because everybody has different learning styles and unless you're finding somebody to curate – like if you're a Ruby programmer and you're trying to learn Python, this is the de facto resource that you need to look at. I think it could be a little bit subjective, but I think that there's still some opportunity there to get community input on what should the interview process be? How long should it really be? How many rounds of interviews should there be from, both the candidates experience as well as the company experience and say, as a business, this is why we have you doing these kinds of things.

That's really what I've been to teach as part of the Tech Interview Guide and the daily email series is from my perspective in the business, this is why. This is why I have you do a certain number of rounds, or this is why I give you this kind of technical challenge, or this is why I'm asking you this kind of question. Because I'm trying to find these signals about you that tell me that you're someone that I can trust to bring on my team. 

It's a tough system when not many people are willing to talk about it because I think a lot of people are worried that others are going to try to game the system and go, “Oh, well, now that I know everything about your interview process, I know how to cheat my way through it and now you're going to give me that job and I really don't know what I'm doing.” 

But I think that at the same time, companies can also have the higher, slow fire, fast mentality of like, “All right, you're not cutting it.” Like you're out right away and just rehire for that position. Again, if you're willing to trust and willing to extend that offer to begin with. If it doesn't work out, it doesn't work out. It's a business decision; it's not a personal thing. But it's still devastating to the person when they don't get the job, or if they get fired right away because they're not pulling their weight, but if they're cheating their way through it, then they get what they deserve to.

MANDY: Awesome. Well, I think that's a great place to put a pin in this discussion. It is definitely not a great place to end it. I think we should head over to our reflection segment. 

For me, there were so many things I wrote down. I loved that you said that people's tech journey is like a choose your own adventure. You can learn one thing and then find yourself over here and then the next thing you know, you find yourself over here. But you've picked up all these skills along the way and that's the most important thing is that as you go along this journey, you keep acquiring these skills that ultimately will make you the best programmer that you can be. 

Also, I really like that you also said something about it being a lifelong learning. Tech is lifelong learning and not just the technical skills. It's the people skills. It's the behavioral skills. Those are the important skills. Those skills are what ultimately it comes down to being in this industry is, do you have the desire to learn? Do you have the desire to grow? I think that should be one of the most important things that companies are aware of when they are talking to candidates that it's not about can this person do a Fibonacci sequence. It's can they learn, are they a capable person? Are they going to show up? Are they going to be a good person to have in the office? Are they going to be a light? Are they going to be supportive? Are they going to be caring? That's the ultimate. That right there for me is the ultimate and thank you for all that insight.

ARTY: Well, I really, really loved your story, Ian at the very beginning of just curiosity and how you started your journey, getting into programming and then ended up finding ways to give back and getting really excited about seeing people's light bulbs go off and how much joy you got from those experiences, connecting with another individual and making that happen. 

I know we've gotten on this long tangent of pretty abstract, big topics of just like, here's the brokenness in the industry and what are some strategies that we can solve these large-scale problems. But I think you said some really important things back of just the importance of these one-on-one connections and the real change happens in the context of a relationship. 

Although, we're thinking about these big things. To actually make those changes, to actually make that difference, it happens in our local context. It happens in our companies. It happens with the people that we interact with on a one-on-one basis and have a genuine relationship with. If we want to create change, it happens with those little ripples. It happens with affecting that one relationship and that person going and having their own ripple effects. We all have the power to influence these things through the relationships with the individuals around us.

IAN: I think my big takeaway here is we have been chatting for an hour and just how easy it is to have conversation about hey, what if we did this? How quickly it can just turn into hey, as a community, what if? And just the willingness of people being in the community, wanting to make the community better, wanting to help build up other people around them to make something better about tech. There are a lot of things broken in tech. I'm a white guy in tech; I've been a part of the problem. I will admit that very forthrightly. 

But my main takeaway here is how easy it is to just sit down and have conversation with people, who I've never met before, and still come up with great ideas and collaborate and just be open to ideas, open to perspectives. I'm walking away from this conversation going now, I wonder what it would take to go build that open source collective on shaking this thing up. Who do I know at different companies that would be open and willing to help back this and put their name on it? Who do I know at different companies and who do I know in different upper management types of positions that would be willing to take a chance and say, “You know what, we're going to try this a little bit different for a quarter and see what kind of impact it has on our team and kind of impact it has on our hiring,” and then report back? Do that agile feedback of try a thing, get some feedback, make a change. 

I love that we can just sit down and have conversation about it. It doesn't have to be polarized. It doesn't have to be politicized. It can just be, “Yeah, this is not working. What idea do you have?” I love that you're both willing to entertain ideas and present ideas and I appreciate the concept now. I actually want to go do something about it. 

So if anybody listening to this wants to do that, you can reach out to me. I'm on techinterview.guide. My email's on there. My LinkedIn's on there. You're welcome to contact me at any point and I would love to keep this conversation going. 

Arty, I'd love to pick your brain a little bit more. And Mandy, if you've got ideas about this, too, let's start pooling this stuff together. Let's start being that change.

ARTY: That sounds great. 

MANDY: Thank you.

ARTY: Thank you, Ian so much for joining us on and I agree, we should totally keep this conversation going. This is how magic happens, right? 

IAN: Sure.

ARTY: You have connections and relationships that form just in the context of having a conversation like this and maybe we can kickstart something awesome.

MANDY: Heck yeah! Well, thank you everyone for listening and we'll see you all next week.