Just because it's hard to do technical interviews well doesn't mean that doing them well isn't worthwhile.
In my technical interviews, I look to talk through specific technical problems, and they're usually real-world bugs or design issues I've worked through in my job. There's not usually a lot of code involved, and the code isn't that tricky. It doesn't usually even rely on too much specific domain knowledge. It's about being able to take a broad technical question, formalize it a little into something concrete enough to be discussed, identifying constraints on the solution, working towards a solution, reasoning about performance, and discussing tradeoffs of this approach vs. others. In short, it's about technical reasoning. I don't care if we get to the right answer by the end if we've had a fruitful technical discussion.
Code samples are a good idea, but they're as deeply problematic as interviews. Most of the code from most of the best engineers I know is closed-source, not on github. 48-hour programming projects can tell you what someone can cobble together, but they don't say anything about the person's attention to longer-term concerns around design or code quality. Moreover, being able to code up a technical solution to a 48-hour problem is like basic literacy: I expect at least that, but I really want to find people who can make forward progress on the uncertainties associated with a 3-month project, at least.
In my technical interviews, I look to talk through specific technical problems, and they're usually real-world bugs or design issues I've worked through in my job. There's not usually a lot of code involved, and the code isn't that tricky. It doesn't usually even rely on too much specific domain knowledge. It's about being able to take a broad technical question, formalize it a little into something concrete enough to be discussed, identifying constraints on the solution, working towards a solution, reasoning about performance, and discussing tradeoffs of this approach vs. others. In short, it's about technical reasoning. I don't care if we get to the right answer by the end if we've had a fruitful technical discussion.
Code samples are a good idea, but they're as deeply problematic as interviews. Most of the code from most of the best engineers I know is closed-source, not on github. 48-hour programming projects can tell you what someone can cobble together, but they don't say anything about the person's attention to longer-term concerns around design or code quality. Moreover, being able to code up a technical solution to a 48-hour problem is like basic literacy: I expect at least that, but I really want to find people who can make forward progress on the uncertainties associated with a 3-month project, at least.