You are taking diversity of thought comment, which I mentioned as an attribute of a team and trying to apply to an interview, which is not what I intended. Your interview processes need to ensure that you do not hire based on biases, so that you will have a diverse team.
Also interview processes are not just interviewer protecting against his/her bias, but also against bias of interviewee which seems to be somehow lost in these discussions.
Lack of diversity of thought is easy to spot IMO. Bigger point is - you should ensure your processes are setup to at least try to achieve the kind of diversity you would like to achieve. Those processes may still fail, just like anything else.
> Did this result in poorer job performance for the DevOps team, or any other negative business results that were specific to that team? If not, who’s to say which interviewing method was better or worse?
It did. And even if it had not in this particular case, it will hurt the company in the long run. There is not even a shred of doubt in my mind that diversity (of thought) is the best investment that leads to success.
I have been using scripted interviews, the same method I mentioned in original comment, for more than 5 years now, hiring more than 200 engineers in three continent and I am super happy with my results.
Having unscripted conversations is one of the best way to be swayed by unconscious bias in interviews.
Even though this advice sounds awesome, I will be cautious of putting it into practice without thinking through the bias problem.
I do remember reading multiple research papers on this, but unable to find them at the moment. From anecdote - In the last company I worked in London, only one team (DevOps) did not follow scripted interviews. It was the least diverse team, not just in terms of representation, but in terms of diversity of thought. Most of it was comprised of "tech-bros".
Scripted interviews do not mean you ask through a basket of questions. It just means that you stay within the guardrails of a set of topics and you go through all the topics. With in a topic, you have fair amount of flexibility. For example if you are hiring for a mid level Java programmer your topics may include - Java 8, Testing pyramid, Functional programming, type safety, developer safety(CI/CD/Rollbacks/Code reviews/Pair programming etc), some domain specific knowledge and so on.
I never been to silicon valley, so my knowledge about it is extremely limited. But last couple of years, I am hearing so many stories from big tech companies - from google to facebook to snapchat to uber - that I wonder if there is a big culture issue in valley based companies.
Most of the hiring is geared towards what do you know instead of how do you solve problems.
I recently went to work a two big company, which is considered highly agile and progressive. I was tasked to build a pricing engine to customize prices for a static inventory of products. Number of products were about 30 and did not change month to month. The architecture suggested we use close to 18 different technologies, including caching systems, message bus, reactive programming. All to give 10 possible prices for 30 products. So essentially 300 values and a system to change the rules which determined the prices based on 3/4 parameters. I built the entire system in 2 days which was ready to be tested, but was told to scrap the work as it did not follow the internal development guidelines. Not to mention I was reprimanded for not including team and calling a complex problem trivial as it increased signaling risk internally. Apparently they are still building that system with 5 engineers, 2 analysts, 1 devops person, and 1 team lead. I left the company 2 years ago. And interestingly each and every person on the team got a promotion, multiple performance bonuses in last 2 years.