Soft Skills Engineering - Episode 43: Internship Costs and CS Interview Questions

Episode Date: January 16, 2017

Dave and Jamison answer these questions: What do internships cost companies? How do you feel about asking hard technical computer science questions in interviews? The second question was prompted by this tweet: In 20 years of engineering I've never said, "thank goodness we hired someone who can reverse a b tree on a whiteboard while strangers watch"— Samantha 🐝 Quiñones (@ieatkillerbees) December 14, 2016

It takes more than great code to be a great engineer. This is the Soft Skills Engineering Podcast, Episode 43. I'm your host, Dave Smith. I am also your host, Jameson Dance. It's a new year. It is. I mean, technically, our last episode came out in the new year as well. Oh yeah, good point. This is the first episode we've recorded in the new year. Yeah, it feels great. I'm a whole new person. Me too.

Um, the first thing I did on January 1st was eat like a one pound bag of Skittles. So I'm really starting it off right. Yeah. And then I went and hurt my back at the gym. Oh, geez. I've developed a tolerance to one pound bags of Skittles through repeated exposure. So I'm, I'm. That's going to come in handy in the Skittle apocalypse.

We have to eat our way out of them. only one man can save us uh yeah so basically my new year's resolutions are all going according to plan excellent my back is hurt my skittles are consumed i'm ready to sell out to big tobacco that's my last resolution i saw somebody tweet something about that oh that's funny yeah anyways this is a show where we answer your questions uh about non-technical aspects of technical fields like software development well only software development yeah i mean and once in a while we get into bridge building but if anyone is like a chemical engineer and you have soft skills

questions i'm sure how hard could it be right we'd answer them i know it's like easy right compared to software development yeah my co-worker keeps spraying my foot with this solution how do i approach him or her with my gigantic foot oh chemical engineers unite uh let's let's answer some questions yes we do have some questions would you like to read one yeah i'll read um yeah i'll read it what do interns cost companies this is from a listener named eric williamson hi champs hey sport hey there tiger back at you bucko uh i'm a computer science student moving from it to programming i'd like to know what are the costs from a management perspective of bringing on an intern i'm having a tough time finding an entry

level development position and i'm not sure if it's because i'm not signaling correctly or if there's a high opportunity cost for potential employers that i don't understand hmm interns okay i need to tell you my favorite intern joke okay which is uh on a mailing list years ago someone wrote in with a technical question about uh how to prevent the screensaver on this linux box from coming on because it was like their monitoring system have i already told you this joke yeah i think you told this on this podcast well for those of you who haven't heard it this is the best. And someone actually said, you don't need to solve this problem. Just hire an intern and have him wiggle the mouse every 20 minutes. Have you seen those intern salary

reports though? Some Silicon Valley companies will pay like nine grand a month for interns for them to wiggle the mouse. Yeah. So that's an expensive program that you didn't write. So tell me if you think I'm lying. I feel like for most companies, internships are part of their recruiting pipeline they they're kind of a high touch high investment recruiting strategy where they will take on interns with the goal of identifying people who will be great full-time employees and making them offers and either um they get enough value out of the interns while they're working that even if they don't end up working full-time it's it's okay um or it's it saves them enough money in recruiting and job postings and all that other stuff that even if

they do get interns that they turn out not to love but it's worth it for the ones that they do love and come on full-time i don't know i think you might really be selling short the idea of wiggling a mouse every 20 minutes i mean that's the other big pipeline the wiggling a mouse every 20 minutes pipeline yeah there's people lined up for that okay uh talk to me and i'll get you something better than that um no i think you're right i think you're absolutely right interns are usually either they are either a pipeline for a direct hire or they are a word of mouth marketing technique to get interns to go back to their colleges and back to their college friends and tell them this is a great place to work but it's it's not just like we need some cheap labor right it's not

explicitly trying to recruit in fact every intern i've ever hired it's probably been i don't know maybe half a dozen to a dozen um the intention has been to convert them into a full-time employee as soon as they graduate and so usually i have only hired people who are within about a year or year and a half from being ready to work full-time and i haven't i haven't ever hired an intern before that like with with a longer lead time than that yeah i've never been the person to say hire don't hire this intern but i've worked on teams that have hired them and it's been a little bit fuzzier than that sometimes it's just we think this person is smart and talented but um they don't have enough experience to come on as a

full-time hire and so we'll we'll do an internship to get to know them a little bit more get them a little bit more experience and then later on they can they can come on full-time so it's kind of like a trial run i guess in those cases did they interview specifically as an intern or did they just come in as a general software developer position without knowing that it could turn into an internship uh no they came in as an intern it wasn't a bait and switch like hey we're not quite ready to make you an offer you're hired walk over to this laptop and wiggle the mouse no it was it was pretty open and honest okay we have danced a lot around the question though

what is the cost of an intern okay so in my experience the financial cost of an intern now i'm not i can't talk about the crazy google oracle microsoft internships but in my experience the cost of an intern financially is very low like on the order of a third to a fourth the cost of a full-time mid to senior level engineer yeah yeah if you're talking about the amount of money that leaves your pocket to pay this person strictly the amount of money yeah that's i would say that's the smallest chunk of the cost though yeah so what's the rest of the cost uh it's the care and feeding of the interns we talked about junior developers and i think in some ways interns is interns are you could kind of look at them like junior developers i don't know there's there's

some crossover there and to make them successful i believe they need uh mentorship and help and guidance not that they're not capable of doing well but just if it's their first job you can't just drop them into this big organization and code base and complexity and expect them to sink or swim uh unless you're willing to watch a lot of them sink so the the effort is or the cost is the effort that your team takes to support them basically and so you pay that i mean if yeah if you want them to come on full time you don't want them to have a miserable experience too yeah yeah and some of it is just even more self-interested than that like i think they'll be more effective if you support them more if you take some time to walk them through the code base

or show them how to deploy correctly so they don't break stuff or there's there's lots of effort to invest that can pay off but it's still effort you have to invest yep absolutely and um you also have to be willing to work around different schedules um because most interns well okay i'll take that back the interns that i've hired they typically will spend the summertime working full-time with my team and then during the school year they'll go back to school and work part-time for my team and during that part-time period you have to be flexible you know they may only work two three days a week they may work early or late hours and they may not be available for all the regular team get-togethers like stand-ups and stuff like that yeah so that's

a price you have to pay as well is that there sometimes is a little bit of extra communication cost to keep them in the loop and make sure you know what they're up to and that they're well well cared for and fed yeah and that might be why some of the interview processes for internships are still relatively strict even though um i mean they're often short term they're often paid less money they're often well sometimes they're given less responsibility so you'd think it'd be like they'd relax the requirements but if if companies are going to invest this much in training they want to make sure that they're training people who they would like to work there full time. Yeah. Yeah. And actually that leads me to an interesting point, which is that

I've seen two kinds of internships and I categorize them this way because the kind of work that the interns do, it ends up being very different depending on which of these two camps the internship falls into. So the first one I'll just call the fog Creek camp, which is a company in New York city that's headed by Joel Spolsky. And he's got some great articles online that describe their internship process but basically they hire interns to build new product like greenfield projects that are started from scratch by this intern team typically taken to like a minimum viable product point and then they try to deploy them to production and so they basically have three months over the summer to go from nothing to something in production that the

company can sell and that's where products like fog creek co-pilot came from and maybe even trello do you know i don't know so that so that's type one um basically you have this independent team of interns they have a senior engineer who will they can they will consult with and they will guide them but they won't really be plugged into the main product development the second kind is the kind that i've done which is where you bring an intern on the team and they are just like any other member of the team they work regular they do regular features they do regular bug fixes just like all the other team members they may have an unpredictable schedule but other than that they are full-fledged members of the team are you saying that those have different costs like you

would invest less in in an intern team that's just kind of off by themselves i think so because a there's less risk you know if they screw up they aren't going to take down your production systems or you know ruin an existing customer experience and so they need less oversight that way b you can kind of just let them run and you don't have to worry about them integrating with company process company communication methods things like that they can just do their thing and then the only time you need to spend with them are getting engineers to consult and guide their efforts but it's not like hey we need to get you ramped up on all of our internal tooling and all of our process right yeah it seems like that might be a uh hmm yeah you'd get two very different kinds

of experience in those two situations you you'd probably get to make a lot more of your own mistakes in the fog creek style one oh yeah but you also might be a little bit a little bit more lost and there's a chance that you would just spin your wheels and do nothing and then leave after three months and then the company would be like well oops sorry sorry we're deleting this code base that you worked on that whole time yeah yeah i think that that's um very actually pretty common uh in the in that style because it's time limited you're basically saying build this you have three months and if at the end of those three months you don't have anything to show for it then oh well you're leaving anyway you know i mean obviously the company doesn't want to just dump

money into this project and have nothing to show for it so you have to put some effort into guiding it yeah so he also mentions he's not sure if he's signaling correctly uh what do you think that means like is he not wearing a nerdy enough stereotypical software developer t-shirt in the interviews or something like that i signaled doctor who but i guess they were more into star truck he's too physically fit i don't know like when people say signaling in an interview context i i get nervous about that that phrase does that strike you a little bit too jameson yeah i mean in a perfect world where everyone is operating off the same assumptions and desires then signaling means doing a good job in the interview assuming they don't have these like secret hoops

you need to jump through or biases or something like that you just you signal correctly by doing well in their interview process when i hear the word signaling in this case i think oh they were looking for a long-term internship and i only want one for three months i should have told them i wanted long term you know something like that yeah and i think at the end of the day your expectations or your needs for your internship just need to be aligned with the companies that you're looking for or else it's not going to be a good experience anyway so better to find that in the interview than to find it three months later yeah so that makes sense so i don't really know that there's a signal that can put people off of a candidate uh falsely in other words um i think

you should tell the truth obviously and there's there's probably a set of requirements that every company has because there's so many different kinds of internships i mean there there are all kinds of signals some of them will be transmitted through smell or okay good point lots of signals i think the key to finding an internship that's going to work for you is finding a company that is looking for what you're ready to offer and then communicating that clearly yeah early on i so i started programming in college and i really didn't know how to actually i knew how to type in some code just a couple months into it but i didn't know how to like sit down and build a program that solved a problem from scratch and i wanted an internship because i wanted to get more

experience and and learn more and work in a place where the the work i would do would teach me those skills but i didn't really have anything to offer uh and i tried a little bit but i just i just didn't get anything because the people that were looking for internships were looking for someone that could contribute in some way not just like a blank canvas that they could do what they wanted with yeah yeah yeah that's a good point and i don't think i've ever hired an intern as inexperienced as you just described yourself yeah it was basically i took the intro to computer programming class and that was and i loved it and and i wanted to do more more uh outside of work yeah so i i think you're right i think um that it could be that in this case our listener eric is actually

not yet experienced enough he says that he um is just switching from it to programming and so it could very well be that you need to wait for another year or two before you're ready to take on an internship and by take on i mean actually do one yeah that could be it could also not be maybe maybe you do just need to wear that doctor who t-shirt like dave said um has has the question been answered i think so okay so question answered all right i'll ask her oh wait wait wait wait we have a sponsor yeah do you want to talk about them yeah sure we uh we are very grateful to uh dev mountain which is a boot camp they are headquartered in provo utah who offer 12-week courses in javascript web development ios development and ux design and they offer

immersive classes with housing provided at really affordable rates and they are sponsoring this show which makes it possible for us to continue delivering amazing quips of wisdom about internships can it can equip were they is that i mean it could be yeah i don't think mine were but theoretically they could be just because we've never seen one doesn't mean they couldn't be yours could be okay yeah right uh so anyway yeah thanks dev mountain for sponsoring us and if you are interested you can go to soft skills.audio slash dev mountain and you can check out the courses that they have coming up and apply to see if you could benefit from a dev boot camp cool do you want to read our next question yes so uh the topic of this question is

asking ridiculously hard theoretical computer science questions in interviews and we got this tweet from listener Craig Doremus who linked a tweet that was written by Samantha Quinones who said in 20 years of engineering I've never said thank goodness we hired someone who can reverse a binary tree on a whiteboard while strangers watch so anyway this was a pretty pretty snarky tweet and it got a lot of attention over 3 000 retweets which is a lot and uh i think a lot of people really agreed with this and it really rung true for a lot of people so so what is your response jameson i am of two minds on the one hand i can totally agree it seems like the the root of this um feeling is why are we asking this stuff in an interview when it is so different from the

actual work we do day to day uh i mean there there's a very small set of engineers who um will write b trees from scratch or even binary trees from scratch but most people will just not do that if you're like writing a database even then though there's probably some c++ b tree library that you can use i don't know yeah but but someone wrote that so maybe if your job is to write that you it's really important and you use all this stuff day to day but if you're just like building websites or web applications in general for the most part most of your day is not taken up with solving uh graph problems or dealing with link lists by hand or kind of these stereotypical cs whiteboard questions i think what you're saying is that developers tend to

work at a higher level of abstraction than these low-level data structures yeah i think so so why on earth would you ask about yeah yeah well plus the artificial environment of like do it on a whiteboard not on your computer stand up in front of this auditorium and like like you're in grade school again and solve the problem for the class i do remember one time i was in an interview and they had asked a question not like this but you know in a similar vein and uh i got stumped and i was like you know i had written a bunch of code on the board i'd drawn a bunch of test cases and stuff like that and they said what would you normally do in a situation when you're stuck like this? And I said, well, I would run it on a computer and see what the output is.

And they kind of laughed. And I think the point was not lost on the interviewer. Yeah. So yeah, I can see the complaints about it. On the other hand, if I'm being kind about their motivations, I think companies can ask these kinds of questions because they believe if someone can solve these kind of problems it proves that they're smart and that they're great developers and good at thinking analytically and then they'll they'll be good productive programmers so it's kind of like to to the interviewers it's a proxy for for coding skill that they can judge yeah yeah i don't know that that's necessarily a great proxy but i could see there being some correlation where if you are really good at this stuff then probably you're you can crank

out features that is i think that is totally right and i i'm i don't mean to say that it's definitely a good proxy what i mean to say is that is why companies ask questions like this is that they believe it is a proxy for basically an aptitude for solving problems with the computer yeah i mean some of the problems are one you learn this stuff in computer science programs and lots of people programmed that didn't do computer science so either they never learn it or they go through like tons of fake interview prep where they just study up on all these questions to go interview at companies it's not improving their ability to get work done it's improving their ability to signal in the interview right that they can get work done and ideally

those would be the same thing you would get better at your job and that would make you better at an interview process but in this case you could argue all this effort is just to make you a better interviewee not necessarily to make you better at your job yeah that sounds totally right and i agree with that um i've also heard um people say this not this tweet in particular but lots of other tweets have said that as a candidate they felt um like the interviewers treated them badly when they put them through this kind of question and uh you know typically it's like well they sat across the table, they had their arms folded, they looked, you know, they were being snarky or whatever. And I hear that a lot, like where people feel intimidated or borderline abused.

I don't think it's necessarily abuse, but you know, in that same ballpark. And I think to myself, if you took away the ridiculous computer science trivia, would that interviewer suddenly be respectful and kind? Or, you know, in other words, is the CS trivia really the problem? Or is it the person who's doing the interview so so you're saying that if they were asking a different kind of question but in the same environment and it still is perceived as like adversarial then the interviewer is kind of a jerk and they should get better at their interviewing skills yeah in other words cs trivia did not make the jerk an aggressive jerk yeah i i think that people perceive these questions as tests that they have to pass and even just the setup of the room like if you're

doing a conversational interview you're kind of just sitting down and talking with another person but as soon as they say i have this problem i would like you to solve now stand up in front of the room and do it um i don't think you need to be a jerk to make that a a stressful situation for people good point because people fear public failure and uh yeah just that idea that it's like pass this challenge to prove you are worthy and and that that that's a stressful thing and that's different from asking you about your experience where you're just talking about stuff that you know like you know your experience so i think some of it is inherent in in the kind of in the question and the environment that the questions are asked, not necessarily

that the interviewer is a jerk. That's a really good point, which I think means that as an interviewer, you need to go way out of your way to put your candidate at ease or else you're going to get a bad reading anyway. You know, you're going to bias the output of the interview process. Sure. I mean, one easy way to do that is do it on a computer. Like Dave said, If your goal is to see them solve a problem as a proxy to see how they would solve problems at work, make it as similar as possible to how they would work. Give them a whiteboard if you want, because sometimes it can be really helpful for people to draw stuff out. But they should have a computer with their own editor with syntax highlighting where they can run stuff and try it out. I don't know, that seems like a no-brainer.

The artificial constraints on the problem, I think, are just cargo culted down from interviewers or other from interviews past. Yeah, I think you're probably right. And there's also a really big risk to asking computer science trivia, which is that you can have candidates who ace your interview process, not because they're great engineers, but because they just, by coincidence, happen to be familiar with the trivia that you happen to ask about. and yeah this has happened to me in two occasions and it took us months to realize that we had thought that this candidate aced the interview but actually they just happened to have a very narrow interest in this particular set of problems and very little other experience or really applicable skills and yeah it was it was just a big mistake on our part yeah i feel like the purpose of an interview is to identify someone's strengths and weaknesses

and see if they match up with what you need for that role not to see like can they solve this one specific problem and you can use that problem to identify like oh they're really they're really sharp at like algorithmic problem solving or they know their data structures really well or maybe they don't but they're really good at talking through and identifying like product issues or yeah so it's it's not like the central core of an interview in my mind it's it's one data point we're out of many but it seems like lots of interview processes are uh can they talk to me and not i don't know not sound stupid about some random stuff and then can they solve the hard problems that we throw at them so yeah i i could see them having a place but

not being the central thing i i guess one other thing is companies are so worried about bad hires because they feel like the cost of a bad hire is is so large that they're really biased towards um rejecting potentially good candidates and these questions i think serve that purpose where there are lots of great developers who can work well on teams and solve problems well and produce good products who might not have the CS background or might not have the like social skills to perform their knowledge in front of a crowd. Right, right. So it seems biased towards rejecting and filtering people out,

which is how lots of interview processes are designed. Yeah, exactly. Because they would much rather have a false negative than a false positive. yeah they want a reason to reject people and this is as i mean it's as good a reason as any i guess like yeah so i'll tell you a little story about that actually sure one of my friends this is not actually me this is actually one of my friends they had a standard interview question which was detecting cycles in a linked list oh man and what it came down to was that one person on their team had stumbled across this legendary algorithm i think it's called the tortoise and the hare algorithm have you ever heard of this one yeah it's in cracking the coding interview oh is it

okay and a bunch of other like job interview prep this one interview uh one interviewer had this idea that if anyone could solve this problem they would just that would be a great proxy for them being an amazing engineer and they asked candidate after candidate after candidate and no one could solve it and this one engineer seemed to take really great pride in the fact that he knew the answer and none of them none of the candidates did right yeah just absolutely absolutely toxic and then one day a candidate came in who they probably read the book right yeah but they came in and they knew the answer and they laid it out on the whiteboard and the guy was just like awesome you know like this is this is the legendary candidate we've been looking for

they have pulled the sword from the stone yeah but it turned out that interview question taught them nothing about that candidate other than he knew the algorithm that was mentioned in this book that that's the only thing it taught them and um and i think eventually they got rid of it but but it was a lot of candidates who they basically learned nothing about whether they knew it or didn't know it i think interviewing might be the hardest thing to do well that's related to software development it's the hardest soft skill i think it is i think it's really hard to do well yeah i think so too so here so i think so far we've been focusing on why cs trivia is a bad idea and i stand behind cs trivia being a bad idea but i i do think that computer science questions have a place in

the interview process and i don't know if jameson will agree with me on this one but you know probably not um and i think that is that they give you a small enough problem that you can fully explore it in the space of a 30 to 60 minute interview and they basically scope it down and you know i've done i have wanted so badly to bring a candidate in and have them just work on my code base with me the problem is it takes days to get ramped up on the code base have you ever done that? I've heard it done once where an interviewee came in and pair programmed with another developer for a half a day. And then the closest I've come outside of that is asking candidates to take a few hours during the interview process and build a small product that they could demo at the end of

it. Sure. But I've never personally had someone work with me on my code base. Sure. But I have ramped up a bunch of engineers on my code bases and i know it takes more than 30 to 60 minutes you know yeah i mean it takes more usually takes more than a day or two to even explain to them how the whole system works yeah so so your argument is um this kind of constrained algorithmic problem if you pick one that isn't like do you know this already but you could reasonably work through with them and and do it in a non-adversarial way will give you a good handle on their ability to solve to solve problems in your code base yes so again it's a proxy right and so but during this during this time i'm not just sitting there with my hands folded over my chest and you know

scowling at them instead i'm i'm working with them and i tell them at the beginning of the interview hey i'm going to give you a problem to solve and i would like you to see what it's like to work with me and i want to know what it's like to work with you so i'm going to offer suggestions and i just i identify the elephant in the room right away and i say look i already know all the solutions to this problem you know so it's totally artificial but we're just going to role play and and i'll give you suggestions just like i would you know in a normal um like peer-to-peer interaction at work and i will ask you questions and stuff like that just as if i was working with you on the problem sure and and then we work through it and that gives me a chance to say

things like hey have you thought about this approach and see how they respond do they reject my ideas do they incorporate them do they fully understand them are they able to communicate rationally about their solutions are they able to defend their choices are they you know there's so many things we do as engineers that are more than just whipping out the code you know we we talk through problems together and we find solutions and so this gives me a nice constrained problem to see how they interact with me and uh when they're working through a problem they haven't seen before yeah that seems like the best uh defense of the dcs style problems that i've seen and i have interviewed using these kind of algorithmic problems um attempting to match

that ideal where you're trying to make it feel like a real thing you're not being a jerk to them you're not just trying to stump them i've also spent a lot of time just working with people in interviews just pairing with them and while they can't learn the whole code base working on what on your actual product yeah on actual like i'll just take what i'm doing today and be like okay let's pair on this and while they can't understand the whole system and you do spend some time explaining like don't worry about this part here's like a 30 second explanation that doesn't get at the the real details of what this does but ignore it for now it still feels like i i learned pretty well how they think is it based on like what kind of questions they ask you or what like what kind

stuff yeah yeah it's it's how do they go about exploring the the boundaries of what we're working on what do they throw away what do they decide to work on how do they because they have to narrow it down to something that they can solve um so so they they have to kind of like section off parts of the problem into what they can understand and work on right now yeah and that's a skill that comes into play a lot in development and then it's just like once you get down to okay they understand they've understood the problem well enough it's small enough that they can solve it without having to worry about other parts of the system then you just see them code on it you you work together on it and see what their code is like and i feel like that's been really helpful

um and it isn't a proxy it is what you would do if you repair programming with them just compressed into like an hour or two so i think you can do that i think the cs thing the way you describe dave is is probably helpful and not as harmful as the way a lot of people do it but i think yes not as harmful well if you do it it's never harmful but i'm ringing in not everyone has the dave skills it's not that bad but i think if you're trying to get a proxy for what it's like to work with them just try working with them and see how it is yep maybe that doesn't scale to giant companies and interviewing like thousands of engineers and there are hundreds of interviewers and but yeah but that doesn't describe most engineers right most engineers

are on small companies medium-sized companies and i don't know maybe but i i am so yes okay i want to change the subject a little bit i want to talk about this sentiment because this this sentiment is very popular where someone says i've never had to reverse a binary tree on the job. So why do you ask it in an interview? Right. And I feel like there is some bias going on here because every engineer at some point in their life is going to be a candidate, right? So we all empathize with candidates in the interview process. Sure. Many of us will also be interviewers. And so, you know, we also, some of us empathize with the interviewers. Very few of us will be companies who have to pay the cost of hiring someone who didn't work out. So there's like

very little representation in the Twitterverse or generally among engineers for the people who had to pay for the mistakes of the bad interviewing process, right? And I think that it's important to remember as we read things like this that sometimes we may not have the context or the empathy that we need to really understand why some of these processes exist. It's just so easy to criticize them and say, well, they're just bad. They're terrible, you know? Yeah. I think you said it in the prep. I don't know if you said it yet that candidates are biased towards wanting an easier interview process too because it makes their life better. Yeah. I want to get a great job and I want it to be easy to get, right? Like we have to all admit that that's going on inside our

heads, even if it's not, even if we would never say it out loud. Yeah. I think some of it definitely comes from that. I think some of it also comes from, um, knowing good people that couldn't get a job at your company because they couldn't pass your interview process, even though you know that they would be great developers. So some of it is a perceived mismatch between, uh, actual talent and what the interview process looks for. But that is a really crappy feeling by the way. yeah yeah it is the worst okay so what is the best cs trivia question the best yes so actually dave you looked up how to reverse a binary tree and we've talked about this a lot as a joke and it's actually not that hard so i seriously just looked it up and it was like oh that's actually

really easy but it was kind of an aha moment for me right like oh that swap all the children around yeah um what's the best one it's the one that i passed and thus i felt really smart about and then watched a lot of people fail the best question is the one you know that no one else does yeah so you can win you've proved you're top of the heap maybe it's something about heaps it's definitely priority heaps where i'm priority one i don't know oh don't fall into that trap so i think if you take nothing else away from this you should take away that as an interviewer it is your obligation to not be a jerk and that the interview process is all about learning about the candidate not showing off

what you know and you really i mean you want to see their best work and people don't do their best work in in adversarial situations often that's right so that's right if you want to see what they can actually do put them in a context where where they will be able to demonstrate their skills and try try try to remove the the burden of the interview which is impossible because you know everyone knows there's a job on the line but you can at least try just tell them they have it already and it's theirs to lose that'll reduce all the pressure we went ahead and made you this offer but now we just want to ask some questions they're just a formality don't don't worry and then take notes on a legal pad

oh really interesting oh you'd put the curly brace there huh yeah scribble scribble scribble scribble pick up your red pen and start writing with the red pen yeah you just tear a sheet out every once in a while okay one one day we need to do an episode on terrible interview techniques so i didn't talk to jameson about this beforehand but if you've heard of awful interview scenarios send them in to us and we would love to hear about the crazy awful things that people have done to you in an interview wouldn't that be fun yeah yeah that would be really cool actually so i'd love that go ahead and hit us up on twitter at soft skills eng and send that over i'd love to

hear it. And if you want to hear more episodes, you can find them at soft skills.audio. Uh, you can also find a Google form there to answer or to ask a question. If you want to give us some more detail, then you can fit in a tweet or a direct message. And I think that's about it. We'll catch you next week. Thanks everybody. See ya.