啲公司覺得用呢種方式起碼確保到false positive candidate比較少,而就算有Max Howell呢啲false negative都可以接受
詳情可以睇吓Cracking the Coding Interview呢本書
This is one of the most common questions candidates have as they get started with this process. Why do things this way? After all,
1. Lots of great candidates don't do well in these sorts of interviews.
2. You could look up the answer if it did ever come up.
3. You rarely have to use data structures such as binary search trees in the real world. If you did need to, you could surely learn it.
4. Whiteboard coding is an artificial environment. You would never code on the whiteboard in the real world, obviously.
These complaints aren't without merit. In fact,l agree with all of them, at least in part.
At the same time, there is reason to do things this way for some-not all-positions. It's not important that you agree with this logic, but it is a good idea to understand why these questions are being asked. It helps offer a little insight into the interviewer's mindset.
This is sad (and frustrating for candidates), but true.
From the company's perspective, it's actually acceptable that some good candidates are rejected. The company is out to build a great set of employees.They can accept that they miss out on some good people. They'd prefer not to, of course, as it raises their recruiting costs. It is an acceptable tradeoff, though, provided they can still hire enough good people.
They're far more concerned with false positives: people who do well in an interview but are not in fact very good.
If you're able to work through several hard problems (with some help, perhaps), you're probably pretty good at developing optimal algorithms. You're smart.
Smart people tend to do good things, and that's valuable at a company. It's not the only thing that matters, of course, but it is a really good thing.
Many interviewers would argue that basic computer science knowledge is, in fact, useful. Understanding trees, graphs, lists, sorting, and other knowledge does come up periodically. When it does, it's really valu- able.
Could you learn it as needed? Sure. But it's very difficult to know that you should use a binary search tree if you don't know of its existence. And if you do know of its existence, then you pretty much know the basics.
Other interviewers justify the reliance on data structures and algorithms by arguing that it's a good "proxy:' Even if the skills wouldn't be that hard to learn on their own, they say it's reasonably well-correlated with being a good developer. It means that you've either gone through a computer science program (in which case you've learned and retained a reasonably broad set of technical knowledge) or learned this stuff on your own. Either way, it's a good sign.
There's another reason why data structure and algorithm knowledge comes up: because it's hard to ask problem-solving questions that don't involve them. It turns out that the vast majority of problem-solving questions involve some of these basics. When enough candidates know these basics, it's easy to get into a pattern of asking questions with them.
It's absolutely true that you'd struggle with writing perfect code on a whiteboard. Fortunately, your inter- viewer doesn't expect that. Virtually everyone has some bugs or minor syntactical errors.
The nice thing about a whiteboard is that, in some ways, you can focus on the big picture. You don't have a compiler, so you don't need to make your code compile. You don't need to write the entire class definition and boilerplate code. You get to focus on the interesting, "meaty" parts of the code: the function that the question is really all about.
That's not to say that you should just write pseudocode or that correctness doesn't matter. Most inter- viewers aren't okay with pseudocode, and fewer errors are better.
Whiteboards also tend to encourage candidates to speak more and explain their thought process. When a candidate is given a computer, their communication drops substantially.