I have interviewed many people, in large and small companies, and saw how interview processes get built in the wrong and right way.
First, here's two reasons why interview processes suck. One, is that no one wants to help recruiting, or HR, do their job. Helping them is an errand and is done in a robotic way. You end up with an idiotic checklist that is a shame to great engineers. Second, is when the team finally realizes idiots joining the team are hurting the team - they will go about and have more motivation to support the recruitment process. Then, when you let a group of people devise such a task you get: an average process designed to leave out the human parts (shift bytes in array) and fit each person's interview style, or a crazy idiotic processes made by people mentally jerking off to each other (implement raft. in assembly). A team can be a company or an actual software development team.
The right way to do it, is this. I believe a single person, who cares about developers, who is passionate about developer experience - should build his/her team's interview process. He/she can take feedback from the team, but that person should eventually build the process and make the calls.
In this specific case I want to believe there is an accurate answer, and a correct answer, and they wanted the correct answer, or at least to see him negotiate his way to the correct answer even though it is subpar (although his accurate answers are impressive). That being said, I'm giving Google credit here. There is a small chance it might just be one of the first options I've described here.
First, here's two reasons why interview processes suck. One, is that no one wants to help recruiting, or HR, do their job. Helping them is an errand and is done in a robotic way. You end up with an idiotic checklist that is a shame to great engineers. Second, is when the team finally realizes idiots joining the team are hurting the team - they will go about and have more motivation to support the recruitment process. Then, when you let a group of people devise such a task you get: an average process designed to leave out the human parts (shift bytes in array) and fit each person's interview style, or a crazy idiotic processes made by people mentally jerking off to each other (implement raft. in assembly). A team can be a company or an actual software development team.
The right way to do it, is this. I believe a single person, who cares about developers, who is passionate about developer experience - should build his/her team's interview process. He/she can take feedback from the team, but that person should eventually build the process and make the calls.
In this specific case I want to believe there is an accurate answer, and a correct answer, and they wanted the correct answer, or at least to see him negotiate his way to the correct answer even though it is subpar (although his accurate answers are impressive). That being said, I'm giving Google credit here. There is a small chance it might just be one of the first options I've described here.