Vox

Leitura de 12 min

Admitting When You Don’t Know

Summary

The episode challenges common bad advice about handling difficult interview questions, particularly for developers. The host argues that the strategy of ‘powering through’ to appear more competent often backfires, making the candidate look worse in the eyes of an interviewer who is evaluating more than just technical knowledge.

From the interviewer’s perspective, the goal is to find someone who will make the team better, succeed at the job, and be trustworthy. When a candidate tries to fake knowledge they don’t have, it directly undermines trust. Even a partially correct answer is less concerning than the act of dishonesty itself. The interview is not just a test of knowledge, but an evaluation of how a person handles failure and uncertainty.

The better strategy, applicable both in interviews and day-to-day work, is to admit when you don’t know something. However, simply stating ignorance creates a dead end. The key is to pair that admission with a proposed action. This could involve leaning on existing team expertise, outlining steps to acquire the necessary knowledge, or suggesting a collaborative approach to solve the problem.

Ultimately, not knowing something is a normal part of a developer’s career of constant learning. The red flags are either faking knowledge or accepting ignorance without a plan. Choosing the route of humility paired with actionable next steps builds the trust necessary to secure a job and collaborate effectively with teammates.

Recommendations

Tools

  • Blue Medora — A sponsor mentioned as a tool for accessing metrics and logs from over 150 technologies and integrating them into monitoring tools like Google Stackdriver, New Relic, Azure Monitor, Wavefront, or Datadog.
  • Google Stackdriver — Referenced as one of the monitoring tools you can integrate with using Blue Medora’s service.
  • New Relic — Referenced as one of the monitoring tools you can integrate with using Blue Medora’s service.
  • Azure Monitor — Referenced as one of the monitoring tools you can integrate with using Blue Medora’s service.
  • Wavefront — Referenced as one of the monitoring tools you can integrate with using Blue Medora’s service.
  • Datadog — Referenced as one of the monitoring tools you can integrate with using Blue Medora’s service.

Topic Timeline

  • 00:00:00 — The problem with bad interview advice for developers — The episode opens by critiquing common bad advice for handling tough interview questions, which often suggests faking confidence. The host, Jonathan Cottrell, states this approach makes you look worse and promises to discuss a better alternative.
  • 00:01:44 — The interviewer’s perspective and what they’re really evaluating — Shifting to the interviewer’s mindset, the host explains that interviewers ask questions with a reasonable answer in mind. When a candidate’s knowledge runs short, the evaluation shifts from pure technical skill to character traits like trustworthiness and how they handle failure. The goal is to find someone who will make the team better.
  • 00:03:50 — The solution: admitting ignorance with humility and action — After the sponsor segment, the host addresses the core question: what to do when you don’t know the answer. He advises admitting a lack of knowledge with true humility, but crucially, not leaving it at a dead end. You must follow up by explaining how you would handle the situation, such as leaning on team expertise or outlining your learning process.
  • 00:07:58 — Why faking it is a red flag and the power of humility — The host concludes by reinforcing that faking knowledge is a dangerous red flag because it suggests you would do the same on the job, harming the team. In contrast, admitting you don’t know something, while initially feeling risky, builds essential trust. The episode ends with the core mantra: always opt for humility and action.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2019-09-30T09:00:00Z
  • Duration: 00:09:02

References

Podcast Info

Transcript

[00:00:00] A lot of bad advice is given about how to handle difficult interview questions.

[00:00:09] This is particularly true for developers.

[00:00:13] Often this advice says to power through it, so that you can appear more competent or confident

[00:00:20] than you really are.

[00:00:22] But the truth is that this advice is only going to make you look worse.

[00:00:27] In today’s episode, we’re going to talk a little bit about what to do instead, and why.

[00:00:34] My name is Jonathan Cottrell, and you’re listening to Developer Tea, and my goal in this show

[00:00:38] is to help driven developers like you find clarity, perspective, and purpose in their

[00:00:42] careers.

[00:00:46] Imagine being in the hot seat again.

[00:00:48] Maybe you have a job right now, but at some point you were interviewed, and if you’re

[00:00:53] like most developers, you were asked questions that maybe you didn’t have.

[00:00:57] What did you do in that scenario?

[00:01:01] You may not even remember now, but maybe you do see this from the interviewer’s side, from

[00:01:08] the person that’s asking that difficult question.

[00:01:11] Now, the key question that’s going to guide the way we think about this is, what do you

[00:01:17] expect, and what do you already know when you ask these questions?

[00:01:23] As an interviewer, you are probably not going to ask a question that you’re not going to

[00:01:26] ask.

[00:01:27] You’re probably not going to ask a question without having some kind of idea for a reasonable

[00:01:31] answer, a good answer.

[00:01:33] And on the flip side, you probably know what a bad answer would be as well.

[00:01:38] But if we return to the mind of the interviewee, the person who is trying to answer this question,

[00:01:44] it’s not so crystal clear.

[00:01:47] We may think that we can answer this question with a passable answer, and look competent

[00:01:53] enough about that given subject.

[00:01:55] But unfortunately, if we try to find a way to answer this question, we’re not going to

[00:01:57] fake it.

[00:01:58] Especially with these kinds of questions, we’re more likely to look bad.

[00:02:03] Now, this is in contrast to a message that we send out on the show all the time.

[00:02:09] Faking it till you make it is actually a pretty good strategy, at least when it’s not in this

[00:02:15] kind of environment.

[00:02:16] In this environment, someone is looking for you to fake it.

[00:02:21] Someone is waiting for you to stumble.

[00:02:24] And not only to stumble, but to…

[00:02:27] To see how you respond to your own failure.

[00:02:30] You can think about it like this.

[00:02:32] Imagine, once again, that you are the interviewer.

[00:02:35] You’re flipping the tables again.

[00:02:37] What are you looking for?

[00:02:38] What are you hoping to see when you ask this question?

[00:02:43] Of course, you may be evaluating some kind of knowledge, but when that knowledge runs

[00:02:47] short, now, what are you evaluating?

[00:02:50] As the interviewee, we feel like we are only being evaluated on our knowledge.

[00:02:57] On our ability to answer these technical questions, like a test in school.

[00:03:02] But the truth is, as an interviewer, I’m looking for someone who’s going to make my team better.

[00:03:09] Who’s going to succeed at the job, and who I can trust.

[00:03:14] If you try to fake it, if you try to make me believe that you know something that you don’t,

[00:03:21] and I can clearly see that you’re faltering, well, I’m going to trust you less.

[00:03:27] Even if your fake-it answer makes some kind of sense.

[00:03:31] If I have a composed question, and I can tell that you are faking it,

[00:03:36] even if you’re kind of getting it halfway there,

[00:03:39] I’m more concerned about the faking it than I am the accuracy of your answer.

[00:03:45] So, of course, the next logical question that you should have is,

[00:03:50] what should we do?

[00:03:51] What should I do in an interview where I don’t have the answer?

[00:03:56] Where the question is,

[00:03:57] is just simply out of reach?

[00:03:59] We’re going to talk about that right after we talk about today’s sponsor, Blue Medora.

[00:04:03] With Blue Medora, you can easily access metrics and logs

[00:04:08] from over 150 on-premises hybrid cloud and multi-cloud technologies.

[00:04:13] You can bring them into your favorite monitoring tool,

[00:04:16] like Google Stackdriver, New Relic, Azure Monitor, Wavefront, or even Datadog.

[00:04:22] You can achieve a single pane of glass that shows your entire stack.

[00:04:27] There’s a frictionless integration,

[00:04:29] and there’s no more dealing with open-source configuration and managing.

[00:04:34] With Blue Medora, you can easily access metrics and logs

[00:04:38] from over 150 on-premises hybrid cloud and multi-cloud technologies.

[00:04:44] You can bring them into your favorite monitoring tool,

[00:04:46] like Google Stackdriver, New Relic, Azure Monitor, Wavefront, or even Datadog.

[00:04:53] You can achieve a single pane of glass that shows your entire stack.

[00:04:57] The integration is painless, and there’s no more dealing

[00:05:01] with open-source configuration or managing monitoring agents.

[00:05:05] You’ll get a visual health dashboard of all of your monitoring integrations,

[00:05:09] and it’s free to install and upgrade your Google Stackdrive monitoring.

[00:05:14] You only pay for the more metrics you stream reflected in your normal GCP bill.

[00:05:19] You can get $200 worth of GCP credit, and these can be combined with their free trial credits

[00:05:25] when you upgrade Stackdriver.

[00:05:26] Blue Medora, New Relic, Azure Monitor, Wavefront, or even Datadog.

[00:05:26] If you want to learn more about Stackdriver, you can find me at

[00:05:28] bluemedora.com slash T.

[00:05:34] Thanks again to Blue Medora for sponsoring today’s episode of Developer Tea.

[00:05:39] So what do you do when you don’t know the answer to a question?

[00:05:43] And really, this goes not only for interviews, but also a lot of the time in our actual work.

[00:05:48] What do we do when we don’t have the answer?

[00:05:52] If we’re trying to save face, if we’re trying to make everyone believe that we are

[00:05:56] something that we’re not, then we can fake it, right?

[00:06:00] And in the real day-to-day, a lot of times faking it actually works,

[00:06:05] but eventually it’s going to fall apart.

[00:06:08] A much better strategy is to approach your lack of knowledge with true humility

[00:06:15] and admit that you don’t know something.

[00:06:17] It sounds simple, but in practice, it tends to be really difficult to do.

[00:06:23] Just because it’s simple doesn’t mean it’s easy,

[00:06:26] but the truth is, when we admit our faults, we can build trust with the people around us,

[00:06:32] especially if those people can help us.

[00:06:35] They can help us learn the things that we need to learn, if needed, or maybe they can partner

[00:06:40] with us so that we don’t have to learn those things. We can just collaborate.

[00:06:45] But it doesn’t stop at just admitting that you don’t know something.

[00:06:49] Dead ends are a terrible place to be in an interview. They’re a terrible place to be in your

[00:06:54] work.

[00:06:56] If you end a conversation on a dead end, then the other person

[00:06:59] will likely lose confidence that you would be able to figure something out.

[00:07:05] So make sure that whenever you admit to not knowing something,

[00:07:09] that you follow that up with some kind of action.

[00:07:12] If you’re going to depend on someone else who does know that thing, if it’s not your expertise,

[00:07:16] but you know someone in the company that does have that expertise, say it.

[00:07:22] Mention that you’re going to lean on the existence of that person, if you’re going to lean on the

[00:07:24] existing expertise on the team.

[00:07:27] If this is related to something that is your responsibility to take care of,

[00:07:32] then explain what your next steps would be.

[00:07:34] How would you gain the knowledge necessary to be able to act in the face of unknowing?

[00:07:40] Ultimately, as developers, we’re always growing and learning new things.

[00:07:44] And so if you don’t know something, well, that’s kind of par for the course.

[00:07:48] But just accepting that you don’t know it and not having an action step to be able to handle,

[00:07:54] that situation, that would be a red flag.

[00:07:58] Faking as if you do know something, that’s also a red flag.

[00:08:01] It’s a dangerous situation to be in because the team will suffer.

[00:08:06] If you fake it in an interview context, then why wouldn’t I believe that you would fake it

[00:08:11] in real life? And if you fake it in real life, then the company suffers.

[00:08:16] Instead, choose the route of humility and action.

[00:08:21] Even though admitting that you don’t know something may feel dangerous,

[00:08:25] it may actually build the trust that you need to get that job or to

[00:08:31] get the buy-in of your teammates. Always opt for humility and action.

[00:08:37] Thank you so much for listening to today’s episode of Developer Tea. Thank you again to

[00:08:40] today’s sponsor, Blue Medora. Head over to bluemedora.com.tea to get started today.

[00:08:46] Today’s episode wouldn’t be possible without spec.fm and our wonderful producer, Sarah Jackson.

[00:08:51] My name is Jonathan Cottrell. And until next time,

[00:08:54] enjoy your tea.

Visão de gráfico