It also doesn't tell me about your personal value system and whether you are passionate about creating good user experiences or if you are just interested in a technical playground or if you are a social climber or what.
It also doesn't tell me if you are highly opinionated and want to do things your own way or if you are flexible enough to deal with the imperfections of the real world. I don't know whether you value the mantra that the perfect shouldn't be the enemy of the good.
No, none of these brain teasers or abstract bootcamp style things tell me that - and those are the actual things that will make or break a company and determine whether your product will hit the market on time. Those are the things that will get you a customer base and will create a company culture of productivity and not something that doesn't lead to results.
Until interviews become more about how people approach work and their ethic and process of conducting it (which is a major part of classical engineering), these are ineffective tools for finding the right people.
---
[1] although as a disclaimer, I strongly prefer companies of under 20 employees. If you have 200, then the employees can be more insulated from the exposure to these types of risk and the necessity of this type of vertical thinking. But it's an "insulation" - everyone is working either directly or tangentially on something that is intended to be used by something in the world (usually humans).
I liked the interview approach of my last job - they had me debug some simple code. This was C++ for gamedev, so they showed me - a class violating the rule of 3 leading to a double delete, some multi-threaded code without memory barriers - or even volatile - and another example that escapes me at the moment. I was able to blitz through that. I floundered slightly when asked to explain the observed behavior of the buggy code pre-fixes - the exact behavior of the multi-threaded code before fixes surprised me, and I couldn't figure out the probable cause in my own head - but that segued easily into a discussion of the disassembly (at which point I was able to explain the behavior) when I suggested I'd look at the disassembly when asked how I'd go about finding out.
They asked about basic usage and design on a broader range of topics as well - I failed to remember to store a salt (doh!) for the simple user DB example schema, and floundered a little on my 3D math skills (in what to apply to solve a problem, not to recite the exact math - an area I admitted up front I was weak in) but otherwise did okay. Also a lot of discussion about previous problems I'd tackled and how (I've got a file of notes I keep called "War Stories".) I ended up getting the job at the price I named - they didn't even try to negotiate me down, perhaps I should've asked for more? :3
I'd be surprised if you're saying this as somebody who doesn't have a track record of working at big name companies who went to a big name school, but you probably are so.