TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

A Humility Training Exercise for Technical Interviewers

349 点作者 ammon超过 6 年前

18 条评论

steelframe超过 6 年前
For the past several years I&#x27;ve become deeply involved in interviewing at my company (hint: it&#x27;s big and is really good at things like search and ads). I&#x27;ve done hundreds of technical interviews here, and I also teach a class to train employees how to interview. I&#x27;m also involved in evaluating candidates who have gone through the interview process.<p>In my position, I get the occasion to read a ton of assessments written by interviewers. Some of the most striking assessments are the ones where the interviewer is cock-sure that they completely nailed the candidate&#x27;s utter and complete incompetence. It&#x27;s usually an interviewer who&#x27;s been asking the same question dozens of times over a year or more. They&#x27;ve seen every variation of performance on the question, and they&#x27;ve completely forgotten what it was like for <i>them</i> when they first encountered a question like that.<p>It&#x27;s total lack of empathy at that point, and if the candidate doesn&#x27;t exude near-perfect interviewing brilliance on that specific question, the interviewer judges them as essentially worthless. Interviewers like that sometimes even get snarky and rather unprofessional in their writeup, &quot;Finally, time ran out, mercifully ending both my and the candidate&#x27;s misery.&quot;<p>If I were to diagnose one of the causes of this phenomenon, I&#x27;d say it is bias. The interviewer best remembers the candidates who performed exceptionally well on their question, triggering the availability heuristic.<p>There are tactics that I think can be effective to bust those biases. One might be to put an upper limit on the number of times an interviewer is allowed to ask any given question. Once they&#x27;ve asked maybe 20 or 30 candidates the same question, it&#x27;s spent. They have to move on to something substantially different.<p>There are some other experiments I&#x27;d like to run. One of them is to have interviewers go through a one-hour interview themselves for every 50 or so interviews they give. Maybe match up an interviewer who has a track record of being especially harsh on candidates for not giving a flawless performance on the question they&#x27;ve been asking for a while. The idea is to see if we can&#x27;t bubble up some empathy.
评论 #19081082 未加载
评论 #19082314 未加载
评论 #19081463 未加载
评论 #19081282 未加载
评论 #19080893 未加载
评论 #19081958 未加载
评论 #19082725 未加载
评论 #19081719 未加载
评论 #19082568 未加载
评论 #19082472 未加载
评论 #19082304 未加载
评论 #19082875 未加载
评论 #19081451 未加载
评论 #19083125 未加载
评论 #19085335 未加载
评论 #19082465 未加载
评论 #19083086 未加载
评论 #19083501 未加载
评论 #19083752 未加载
评论 #19083335 未加载
评论 #19081837 未加载
评论 #19083261 未加载
评论 #19097979 未加载
评论 #19083524 未加载
评论 #19081112 未加载
评论 #19083411 未加载
评论 #19080778 未加载
评论 #19082926 未加载
评论 #19081749 未加载
cgearhart超过 6 年前
This is a great suggestion that closely aligns with my own thoughts and experiences with technical interviews.<p>I&#x27;ve had some recent experience with technical interviews, and my first big takeaway was that the current interview process is broken largely because it&#x27;s too common for the interview to never surface the _strengths_ of a candidate, and instead only to highlight their weaknesses. For every candidate, there is literally an infinite number of things they do not know. Surfacing those deficiencies has no purpose or value unless those weaknesses are _directly_ relevant to the job role–which is hardly ever the case when talking about DS&amp;A questions.<p>The second lesson I learned is that interviewers need more training because there is a <i></i>vast<i></i> difference between good and bad interviewers–and almost all of it comes down to communication skills. If we don&#x27;t finish a warm-up problem because it takes me 30 minutes to decode and understand the question that the interviewer is trying to ask...that&#x27;s a problem.
评论 #19080902 未加载
评论 #19080879 未加载
o10449366超过 6 年前
Unfortunately, some insecure developers sign up to be interviewers precisely to feel superiority and power over interviewees. I&#x27;ve both worked with and been interviewed by some of these people - they seem particularly prominent in the valley. Anecdotally, Google was the worst of the big tech companies with cocky, condescending interviewers that came in wearing Ivy league sweaters. By contrast, all of my interviews at mid-level tech companies were equally difficult technically, but much more pleasant and engaging.
评论 #19080616 未加载
评论 #19088320 未加载
ammon超过 6 年前
I mostly focus on consistency in this post (how to make a group of interviewers more consistent). Of course, what actually matters is accuracy (predictive utility of the interview). Obviously those are not the same thing (you could run 100% consistent interviews by just having everyone always grade “strong no”). However, I think (based on running the interview team at Triplebyte) that inconsistency is the primary obstacle to accuracy in practice. So I end up spending the majority of my time focusing on how to make interviewers more consistent.
评论 #19081019 未加载
评论 #19080496 未加载
评论 #19079609 未加载
评论 #19081812 未加载
mherdeg超过 6 年前
Interesting idea:<p>&gt; Then, as the interview progresses, do exactly this. About half the time give your best answer. The other half of the time give an intentionally poor answer. ...<p>&gt; What this does is free your co-worker to be 100% honest. They don&#x27;t know which parts of the interview were really you trying to perform well. Moreover, they are on the hook to notice the bad answers you gave. If you gave an intentionally poor answer and they don&#x27;t “catch” it, they look a little bad. So, they will give an honest, detailed account of their perceptions.<p>This reminds me of the second part of the Rosenham experiment [ <a href="http:&#x2F;&#x2F;psychrights.org&#x2F;articles&#x2F;rosenham.htm" rel="nofollow">http:&#x2F;&#x2F;psychrights.org&#x2F;articles&#x2F;rosenham.htm</a> ]:<p>&gt; The following experiment was arranged at a research and teaching hospital whose staff had heard these findings but doubted that such an error could occur in their hospital. The staff was informed that at some time during the following three months, one or more pseudopatients would attempt to be admitted into the psychiatric hospital. Each staff member was asked to rate each patient who presented himself at admissions or on the ward according to the likelihood that the patient was a pseudopatient. A 10-point scale was used, with a 1 and 2 reflecting high confidence that the patient was a pseudopatient.<p>&gt; Judgments were obtained on 193 patients who were admitted for psychiatric treatment. All staff who had had sustained contact with or primary responsibility for the patient – attendants, nurses, psychiatrists, physicians, and psychologists – were asked to make judgments. Forty-one patients were alleged, with high confidence, to be pseudopatients by at least one member of the staff. Twenty-three were considered suspect by at least one psychiatrist. Nineteen were suspected by one psychiatrist and one other staff member. Actually, no genuine pseudopatient (at least from my group) presented himself during this period.<p>There is a version of this exercise you could do where you <i>say</i> you are intentionally giving bad answers and give none!!!
评论 #19082216 未加载
rhizome超过 6 年前
I&#x27;d be interested to see what happens if an interviewee turns the table under the guise of &quot;interviewing the company,&quot; which is a concept promoted from time to time in interviewing threads.<p>When your interviewer is telling you about their role in the company and a little about their history (if they have one), say it&#x27;s a dev interview because why not, ask them how they rate their programming skill on a scale from 1 to 5. Ask them why they left their last company. Ask them what the most difficult thing they&#x27;ve ever achieved is.
评论 #19080700 未加载
评论 #19079913 未加载
malvosenior超过 6 年前
This is great. I seriously doubt most interviewers could pass the technical tests they give out if they were incurring the huge cognitive load of interviewing for a company while trying to do it.<p>I&#x27;d love to see actual pair programming with interviewer and interviewee. Where they were assigned a random (small) code project and had to work on it together with neither having prior knowledge. It would level the playing field a bit and is much closer to actual working conditions than being forced to write code under duress and close real-time examination.
评论 #19080495 未加载
评论 #19080137 未加载
sonnyblarney超过 6 年前
Very good points, agree with it.<p>However - I don&#x27;t think this is about &#x27;ego&#x27; or even &#x27;humility&#x27; - I think those are not the right words.<p>It&#x27;s a lack of contextual understanding both in &#x27;self awareness&#x27; and also the interviewers plight.<p>I think the premise can be taught.<p>Also, I think interviews can be structured to find qualities independant of background.<p>+ Questions that don&#x27;t measure a person&#x27;s ability to &#x27;memorize algorithms&#x27; are a good start.<p>+ Allowing devs to pick their language of expression, i.e. sometimes they are more comfortable in one lang than another.<p>+ Don&#x27;t get syntax&#x2F;code structure confused with the abstract problem if that&#x27;s what one is going for. Google has a nice interview example [1]<p>+ Open ended questions with many possible turns allow for a &#x27;good&#x27; thinker to just go a lot further, and be more impressive while at the same time allowing junior devs to still walk through and complete something. The Google example is again good here.<p>+ Time&#x2F;on the spot - one of the worst issues. Personally I&#x27;m about 50&#x2F;50. Sometimes &#x27;in the flow&#x27; sometimes &#x27;not&#x27;, but surely just given a little bit fo time, I&#x27;d be fine on most things. For this reason, giving interviewees an intro to the problems, and giving them as much time as they want to think about them before the interview starts, might be worthwhile as well. &#x27;Let us know when you want to go over a solution&#x27;. This could work well for pedantic things such as &#x27;here&#x27;s some code, find some bugs&#x27; or &#x27;how would you structure this differently&#x27; etc..<p>[1] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=XKu_SEDAykw" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=XKu_SEDAykw</a>
nobodyandproud超过 6 年前
I went through one of TripleBytes interview processes. The interviewer was smug and condescending<p>Thankfully it was remote and not during my work hours, so little was lost.
klrr超过 6 年前
Why not pick a problem the interviewer have not solved, and let the interviewee and interviewer solve the problem together. This shows how the candidate is thinking, and how they are working together with others. It will also let the interviewer get a more un-biased view of the difficulty of the algorithm or CS problem.
paulie_a超过 6 年前
Give pointers if necessary in a technical interview, see what questions they ask. If they are completely flubbing it and you already know it is a no go, call it off. It&#x27;s a little shocking to hear but in a few minutes they will generally be grateful&#x2F;understanding you didn&#x27;t waste two more hours of their time.
garrettr_超过 6 年前
“What this does is free your co-worker to be 100% honest. They don&#x27;t know which parts of the interview were really you trying to perform well.”<p>Since there was no mention of it in the post, this is called “randomized response,” and is a building block for modern privacy-preserving protocols e.g. RAPPOR, which is used in Google Chrome: <a href="https:&#x2F;&#x2F;security.googleblog.com&#x2F;2014&#x2F;10&#x2F;learning-statistics-with-privacy-aided.html" rel="nofollow">https:&#x2F;&#x2F;security.googleblog.com&#x2F;2014&#x2F;10&#x2F;learning-statistics-...</a>
User23超过 6 年前
There are some factors that affect interviewee performance that are seldom considered. The stand-out I noticed is that the quality of whiteboard coding is a function of whiteboard size, the bigger the better.
rb808超过 6 年前
Nice. I also feel like I need humility training to work with and evaluate newbie devs. They cant do anything right. Not sure if its just hard to find people who know what they&#x27;re doing or I&#x27;ve forgotten what its like in your first few years.
tacomplain超过 6 年前
I dont really agree with ego = 1&#x2F;knowledge; I believe that my knowledge over time has been increasing and my ego has been fluctuating in a non correlate way.
antoinevg超过 6 年前
Brilliant.
mentally_broken超过 6 年前
.
评论 #19082103 未加载
bra-ket超过 6 年前
why interviewing is not automated yet
评论 #19107088 未加载
评论 #19080306 未加载
评论 #19079898 未加载