A lot of bad advice is given about how to handle difficult interview questions. This is particularly true for developers. Often this advice says to power through it so that you can appear more competent or confident than you really are. But the truth is that this advice is only going to make you look worse. In today's episode we're going to talk a little bit about what to do instead and why. My name is Jonathan Cutrell and you're listening to Developer Tea and my goal in this show is to help driven developers like you find clarity, perspective, and purpose in their careers. Imagine being in the hot seat again. Maybe you have a job right now but at some point you were interviewed and if you're like most developers you were asked questions that maybe you didn't have an immediate answer to. What did you do in that scenario? You may not even remember now but maybe you do see this from the interviewer side, from the person that's asking that difficult question. Now the key question that's going to guide the way we think about this is what do you expect and what do you already know when you ask these questions. As an interviewer you are probably not going to ask a question without having some kind of idea for a reasonable answer, a good answer. And on the flip side you probably know what a bad answer would be as well. But if we return to the mind of the interviewee, the person who is trying to answer this question, it's not so crystal clear. We may think that we can answer this question with a passable answer and look competent enough about that given subject. But unfortunately if we try to fake it, especially with these kinds of questions, we're more likely to look bad. This is in contrast to a message that we send out on the show all the time. Faking it till you make it is actually a pretty good strategy, at least when it's not in this kind of environment. In this environment, someone is looking for you to fake it. Someone is waiting for you to stumble and not only to stumble, but to see how you respond to your own failure. You can think about it like this. Imagine once again that you are the interviewer, you're flipping the tables again. What are you looking for? What are you hoping to see when you ask this question? Of course you may be evaluating some kind of knowledge, but when that knowledge runs short, now what are you evaluating? As the interviewee, we feel like we are only being evaluated on our knowledge, on our ability to answer these technical questions like a test in school. But the truth is as an interviewer, I'm looking for someone who's going to make my team better. Who's going to succeed at the job and who I can trust? If you try to fake it, if you try to make me believe that you know something that you don't, and I can clearly see that you're faltering, well, I'm going to trust you less. Even if your fake answer makes some kind of sense, if I have a composed question and I can tell that you are faking it, even if you're kind of getting it halfway there, I'm more concerned about the faking it than I am the accuracy of your answer. So of course the next logical question that you should have is, what should we do? What should I do in an interview where I don't have the answer? Where the question is just simply out of reach. We're going to talk about that right after we talk about today's sponsor, Blue Madora. With Blue Madora, you can easily access metrics and logs from over 150 on-premises, hybrid cloud, and multi-cloud technologies. You can bring them into your favorite monitoring tool like Google Stackdriver, New Relic, Azure Monitor, Wavefront, or even DataDog. You can achieve a single pane of glass that shows your entire stack. There's a frictionless integration and there's no more dealing with open source configuration and the energy. With Blue Madora, you can easily access metrics and logs from over 150 on-premises, hybrid cloud and multi-cloud technologies. You can bring them into your favorite monitoring tool like Google Stackdriver, New Relic, Azure Monitor, Wavefront, or even DataDog. You can achieve a single pane of glass that shows your entire stack. The integration is painless, and there's no more dealing with open source configuration or managing monitoring agents. You'll get a visual health dashboard of all of your monitoring integrations. And it's free to install and upgrade your Google Stack Drive monitoring. You only pay for the more metrics you stream reflected in your normal GCP bill. You can get $200 worth of GCP credit, and these can be combined with their free trial credits when you upgrade Stackdriver with bind plane at bloommandoora.com slash T. That's bloommandoora.com slash T-E-A. Thanks again to bloommandoora for sponsoring today's episode of Developer Tea. So what do you do when you don't know the answer to a question? And really, this goes not only for interviews, but also a lot of the time in our actual work. What do we do when we don't have the answer? If we're trying to save face, if we're trying to make everyone believe that we are something that we're not, then we can fake it, right? And in the real day to day, a lot of times, faking it actually works. But eventually it's going to fall apart. A much better strategy is to approach your lack of knowledge with true humility, and admit that you don't know something. It sounds simple, but in practice, it tends to be really difficult to do. Just because it's simple doesn't mean it's easy, but the truth is when we admit our faults, we can build trust with the people around us, especially if those people can help us. They can help us learn the things that we need to learn, if needed, or maybe they can partner with us so that we don't have to learn those things, we can just collaborate. But it doesn't stop it just admitting that you don't know something. The dead ends are a terrible place to be in an interview, they're a terrible place to be in your work. If you end a conversation on a dead end, then the other person will likely lose confidence that you would be able to figure something out. So make sure that whenever you admit to not knowing something, that you follow that up with some kind of action. If you're going to depend on someone else who does know that thing, if it's not your expertise, that you know someone in the company that does have that expertise, say it. Mention that you're going to lean on the existing expertise on the team. If this is related to something that is your responsibility to take care of, then explain what your next steps would be. How would you gain the knowledge necessary to be able to act in the face of unknowing? Ultimately, as developers, we're always growing and learning new things. And so if you don't know something, well, that's kind of par for the course. But just accepting that you don't know it and not having an action step to be able to handle that situation, that would be a red flag. Faking as if you do know something, that's also a red flag. It's a dangerous situation to be in, because the team will suffer. If you fake it in an interview context, then why wouldn't I believe that you would fake it in real life? And if you fake it in real life, then the company suffers. Instead, choose the route of humility and action. Even though admitting that you don't know something may feel dangerous, it may actually build the trust that you need to get that job or to get the buy-in of your teammates, always opt for humility and action. Thank you so much for listening to today's episode of Developer Tea. Thank you again to today's sponsor, Bloom Adora, head over to BloomAdora.com slash TEA to get started today. Today's episode wouldn't be possible without spec.fm and our wonderful producer, Sarah Jackson. My name is Jonathan Cutrell, and until next time, enjoy your tea. errand,