Re:The time spent on practising white board test may not be ...
by maxxxxx on Thursday February 15, 2018 @09:45AM
(#16384347)
You seem to have a reasonable approach to interviews. However, as a contractor I was in interviews where I had to code the optimal solution for a certain problem on the whiteboard without syntax errors. That's just silly.
There was no discussion to show any thought process. It was about knowing the expected solution to 100%.
- How well can you converse about a technical topic
- How adaptable are you to design constraints
- Do you understand the fundamentals of threading, databases, data structures, ect?
- Can you "think in code?"
- How well do you really understand the language that you spent XX years of your career working in
The best way to improve your skills is by doing: specifically, choose a hobby project that involves an area that you want to learn. Reading a book will only get you about 10-15% of the way there. Books are useful to choose a technology to learn, but not to learn the specific technology.
Getting back to whiteboarding: I've used it to:
- Reject candidates who forget basic fundamentals of a language that they claim XX years in. (Seriously, if you can't construct an "if" statement or use a common collection class in a language you claim XX years in, then you don't belong on my team.)
- Reject candidates who can't learn an unfamiliar API. This is critical, because we need to discuss new APIs in design discussions; and because "old & working" code isn't always worth refactoring to use some shiny new API.
- Reject candidates who don't know how to use a database. (Frameworks / ORMs are not a replacement for knowing how a database works and how to program with one.)
- Reject candidates who don't know fundamentals of threading