I could not agree more with this. Among other things, I am interested in how a person thinks, how they solve problems, how they communicate and how they face new challenges. For the most part, I could not care less what languages they know today.
My perspective on this is likely very personal. Nearly 100% of the technologies that we use today did not exist when I was in school and started working as an engineer. I am fond of saying that they only things that survive the test of time are C, math and physics.
I do like people with low level experience. By this I do mean assembler. That tells me they did not come-up in an idealized world that is completely isolated from the underlying hardware. I like to remind people that Bjarne Stroustrup was very much into assembler and microcode before creating C++.
My standard test is to learn what language a person does not know and have them solve a problem using it. These days that typically means something like Forth, LISP or, my favorite, APL. Having used APL professionally for ten years, this is one of my preferred go-to interview languages.
I could not give a shit if someone memorized a hundred interview problems (Fibonacci and palindromes make me want to vomit).
I also find that this instantly relaxes the interview process. I'll say something like "I know you don't know the first thing about APL. No problem. I want to understand how you might approach having to write something in a language or framework that is completely new to you. I know the language well. You can ask me anything you want, google it, or, here's a couple of books for you to refer to." We then sit down, hack and talk.
Computational problem solving is a creative as well as technical job. If you want to hire robots who can memorize and spew out hundreds of trained little problems, by all means, go for it. It might be the case that large companies like Google and FB have no choice but to filter this way, I would not know. I'd rather work with people who can say "I have no clue, but I'll figure this out".
My perspective on this is likely very personal. Nearly 100% of the technologies that we use today did not exist when I was in school and started working as an engineer. I am fond of saying that they only things that survive the test of time are C, math and physics.
I do like people with low level experience. By this I do mean assembler. That tells me they did not come-up in an idealized world that is completely isolated from the underlying hardware. I like to remind people that Bjarne Stroustrup was very much into assembler and microcode before creating C++.
My standard test is to learn what language a person does not know and have them solve a problem using it. These days that typically means something like Forth, LISP or, my favorite, APL. Having used APL professionally for ten years, this is one of my preferred go-to interview languages.
I could not give a shit if someone memorized a hundred interview problems (Fibonacci and palindromes make me want to vomit).
I also find that this instantly relaxes the interview process. I'll say something like "I know you don't know the first thing about APL. No problem. I want to understand how you might approach having to write something in a language or framework that is completely new to you. I know the language well. You can ask me anything you want, google it, or, here's a couple of books for you to refer to." We then sit down, hack and talk.
Computational problem solving is a creative as well as technical job. If you want to hire robots who can memorize and spew out hundreds of trained little problems, by all means, go for it. It might be the case that large companies like Google and FB have no choice but to filter this way, I would not know. I'd rather work with people who can say "I have no clue, but I'll figure this out".
Not saying this is the only way, just my way.