| > Interviews will transition to be more real-world scenarios, perhaps within the customer's actual codebase, addressing a genuine problem the customer faces—possibly even compensating the interviewee for their time The mechanics of this idea suck for everybody. Sometimes you have a candidate who is up to speed on your stack or one of its dependencies and can go from idea to implementation in a short time period but otherwise the math doesn't work. A week of time with a mentor for one day over that time is probably enough to do a 2 day task if there are no difficulties when you consider lack of knowledge of the code base and interfacing with a new code environment. So best case scenario you pay 3x for a feature whose mental state won't stick around and the interviewer has to find time to do a week of work while juggling their existing job (which could be job searching if nothing else). You could say "but you would hire them after" but if we are talking about that late in the process probationary periods make more sense. If you aren't sure they are a good fit (say 50% certainty) overpaying for a potential solution is bad and then wasting that much time on a solution also doesn't make sense. That is why most practical things are less than a day of effort and not impactful on the product to avoid weirdness around NDAs/Copyright/proper payment. And if you think meaningful work happens more often than every two days I wonder what software company you are working for... Breaking down tasks to 1 hour slots isn't what I would call a good use of resources... |