Being easy to work with is certainly something interviewers should look for, but software doesn't care how nice you are. Your technical competency should ideally be measured outside of any subjectivity. Of course that's not possible but companies try their best.

Your coworkers definitely care how nice you are, and the degree to which your technical competency matters is gated by your ability to work effectively with the team.

I think it is possible. You can measure technical competency very easily without much human interaction.

It's incredibly difficult to measure technical competency quickly. If you don't spend a lot of time writing string functions then don't ask about them in interviews.

The problem is very few things are short term tasks in isolation. So, someone that takes a while to solve 6h problems can be really efficient in the long term. Worse, short term problems need to fit the same type as what your actually doing.

PS: As soon as someone says "i don't know" you need to stop and realize they would spend a few minutes on google. Spending more time on the topic at this point is pointless.

> PS: As soon as someone says "i don't know" you need to stop and realize they would spend a few minutes on google. Spending more time on the topic at this point is pointless.

Or, give them the answer and see what they can do with the information. IE, pretend that they DID lookup the answer and go from there. Did they grasp the concept? Could they make logical inferences from that new concept? If they can't do it when you tell them the answer, why would you think they could if Google told them it instead?

Googling gives someone time not just an answer. Sure, for trivia an answer is all you need, but trivia is a waste of interview time. On the other hand if someone looks up a formula they can spend 5 minutes actually understanding it which feels like an eternity in an interview.

Remember the context is the Job not the interview. On the job, having not done something for 3 years is a minimal setback for most people as the retraining time is almost meaningless. In an interview that 'highly' skilled person is going to take a long time to get back up to speed.

Can you elaborate?

a) At my uni 15 yrs ago. Write a code that listens on certain input. You upload the source code, a bot compiles it, runs a bunch of functional test, then it tells your score. It didn't help what you missed, just a score, like Your solution passed 225 test out of 250.

b) Find a bug in a source code. Describe the end-user captured bug, and measure the time and the quality of the solution.

c) Simulate a distributed code review and measure the found problems. This can be extended to UX as well.

(These are just quick examples.)