However - I don't think this is about 'ego' or even 'humility' - I think those are not the right words.
It's a lack of contextual understanding both in 'self awareness' and also the interviewers plight.
I think the premise can be taught.
Also, I think interviews can be structured to find qualities independant of background.
+ Questions that don't measure a person's ability to 'memorize algorithms' are a good start.
+ Allowing devs to pick their language of expression, i.e. sometimes they are more comfortable in one lang than another.
+ Don't get syntax/code structure confused with the abstract problem if that's what one is going for. Google has a nice interview example [1]
+ Open ended questions with many possible turns allow for a 'good' 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.
+ Time/on the spot - one of the worst issues. Personally I'm about 50/50. Sometimes 'in the flow' sometimes 'not', but surely just given a little bit fo time, I'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. 'Let us know when you want to go over a solution'. This could work well for pedantic things such as 'here's some code, find some bugs' or 'how would you structure this differently' etc..
However - I don't think this is about 'ego' or even 'humility' - I think those are not the right words.
It's a lack of contextual understanding both in 'self awareness' and also the interviewers plight.
I think the premise can be taught.
Also, I think interviews can be structured to find qualities independant of background.
+ Questions that don't measure a person's ability to 'memorize algorithms' are a good start.
+ Allowing devs to pick their language of expression, i.e. sometimes they are more comfortable in one lang than another.
+ Don't get syntax/code structure confused with the abstract problem if that's what one is going for. Google has a nice interview example [1]
+ Open ended questions with many possible turns allow for a 'good' 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.
+ Time/on the spot - one of the worst issues. Personally I'm about 50/50. Sometimes 'in the flow' sometimes 'not', but surely just given a little bit fo time, I'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. 'Let us know when you want to go over a solution'. This could work well for pedantic things such as 'here's some code, find some bugs' or 'how would you structure this differently' etc..
[1] https://www.youtube.com/watch?v=XKu_SEDAykw