The more I think about it, the more I think I have to say “no comment”. Sorry, I’d have liked to answer.
Instead, have some thoughts:
Curiosity is good. Once you get above the dregs, the #1 problem with programmers is if they feel comfortable not learning anything not important to their job.
There’s a difference between “knowing how to do something” and “understanding how it works, therefore knowing how to do something”. Everyone wants the latter, some don’t realise they want it, but a lot of people settle for the former.
With that said, I imagine we’d hire anyone with either outstanding depth of knowledge or breadth of knowledge, but don’t quote me on that. It’s general advice, definitely not a comment on hiring practices that I’m not that familiar with.
I didn’t mean to ask for actual responses. Fictitious works fine too. I was just trying to identify the boundary.
There’s a difference between “knowing how to do something” and “understanding how it works, therefore knowing how to do something”.
The difference between having a lookup table of solutions, and having an accurate model of the system upon which solutions can be simulated and verified.
I didn’t mean to ask for actual responses. Fictitious works fine too. I was just trying to identify the boundary.
I’d never have provided actual responses. However, even vague descriptions of what we’re looking for risks getting more candidates who have optimised to pass the interview instead of actually doing well in the job. Proxies for ability are necessary, but proxies only work so long as they aren’t common knowledge.
The difference between having a lookup table of solutions, and having an accurate model of the system upon which solutions can be simulated and verified.
That’s part of it, but especially with computers—which are built on abstractions—you can have an accurate model of single layers without really understanding how the layers beneath (or above) work. Ideally, we want people who have reasonably accurate models of all layers.
A lot—possibly most—programmers don’t have that, and therefore fall prey to leaky abstractions on occasion. We can’t afford that, not when potential losses are measured in thousands of dollars per second.
Can you give some examples of responses at the threshold of terrible?
The more I think about it, the more I think I have to say “no comment”. Sorry, I’d have liked to answer.
Instead, have some thoughts:
Curiosity is good. Once you get above the dregs, the #1 problem with programmers is if they feel comfortable not learning anything not important to their job.
There’s a difference between “knowing how to do something” and “understanding how it works, therefore knowing how to do something”. Everyone wants the latter, some don’t realise they want it, but a lot of people settle for the former.
With that said, I imagine we’d hire anyone with either outstanding depth of knowledge or breadth of knowledge, but don’t quote me on that. It’s general advice, definitely not a comment on hiring practices that I’m not that familiar with.
I didn’t mean to ask for actual responses. Fictitious works fine too. I was just trying to identify the boundary.
The difference between having a lookup table of solutions, and having an accurate model of the system upon which solutions can be simulated and verified.
I’d never have provided actual responses. However, even vague descriptions of what we’re looking for risks getting more candidates who have optimised to pass the interview instead of actually doing well in the job. Proxies for ability are necessary, but proxies only work so long as they aren’t common knowledge.
That’s part of it, but especially with computers—which are built on abstractions—you can have an accurate model of single layers without really understanding how the layers beneath (or above) work. Ideally, we want people who have reasonably accurate models of all layers.
A lot—possibly most—programmers don’t have that, and therefore fall prey to leaky abstractions on occasion. We can’t afford that, not when potential losses are measured in thousands of dollars per second.