At the same time, I hear that people don't like work sample tests because they take far too long to complete, or because you feel compelled to work extra.
Has anybody had experience conducting work-sample SWE interviews? What went wrong and what went right? Was it hard to persuade others to change the interview format? Was it hard to figure out what to evaluate?
Alternatively, if you don't have experience running them, do you have any good ideas? Maybe an "ideal" work-sample interview?
------------------------------
I assume I'll have some issues persuading people (both on and offline). Here are my thoughts/rant ATM.
I work in a distributed systems/database area and believe we are testing the wrong skills with generic interviews. It doesn't matter if an interviewee knows how to do LeetCode problem solving if they don't know how to problem-solve with caching strategies and consistency levels because you lack the basic knowledge. And if a candidate doesn't know the above techniques, I care more about their ability to learn the fundamentals (which aren't linked lists). Since a lot of fundamentals are advanced undergrad dist. systems/database concepts, one probably is applying to the wrong role if they haven't attempted to learn them anyway.
This idea should apply to other roles as well. If you're doing frontend, you probably shouldn't be tested on your understanding of Big-O if you work with arrays that scale up to 100 items. Maybe it would make more sense to test on problem-solving with React state instead.
No comments yet.
