instead of asking them stupid, verbatim-recall questions, i give them a problem and ask them how they would solve it.
i.e., "a customer reports his website is running too slow. describe how you would identify and solve the problem."
it's a good sign when they start asking you follow-up questions, like "is it load balanced? is there a database?". it's a bad sign when they say, "just restart the server".
I got asked "what happens when you hit return in the browser?" After I had traced from the keyboard driver through libraries and runtimes to the browser event system, then back down thru the network layers to sockets, then thru IP events to land a packet on the remote router, they called a halt. Apparently nobody had actually answered the question before.
IMO Its a good exercise for problem-solving, and plumbs experience and terminology. I'm not so sure you learn anything about the subject's actual programming skills?
I think that both this question, and beachstartup's question about speeding up a website, are totally decent interview questions, for a intermediate-to-senior web developer.
But if anyone thinks that either of these questions is testing "critical thinking skills", or "problem solving", then I would like to hear in what way. Both of those seem to me to be pretty much archetypal "verbatim-recall questions".
Experience and exposure and education and ability to brute-force recall all of the above is valuable. But it's pretty much the exact opposite of what beachstartup said (s)he was testing, and there is zero "problem solving" in the "what happens when you hit return in a browser" question.
I'm a little bewildered how anyone could confuse these diametrically opposed aptitudes.
True. It takes all kinds of questions to get a good impression.
But I'd just like to protest, my answer was not 'brute-force recall'. It was simple experience. See, I've written code at all of those levels. None of it was booklearning.
I'll start by noting that this sequence of comments is just nit-picking, and if that bores anyone, stop reading. That disclaimer disclaimed...
I don't honestly care if it was booklearning or not, and I don't see what it has to do with my kvetch. I'm happy to believe you that it was learned from experience.
What does "brute-force recall" mean to you? To me it means that you are only repeating things that you knew before the question was asked, as opposed to dynamically generating new knowledge during the time that you answer. Whether you originally got that knowledge from books, or from experience, or from Mr Spock doing a mind meld, it's still memory, as distinct from problem-solving or critical thinking or perhaps more generically we might name "wit" as the counterpart of memory.
Again, I'm absolutely not knocking this form of knowledge; memory without wit is perhaps inflexible, but wit without memory is impotent. Memory is a good thing. Memory makes up the much greater half of expertise; this is why seniors get paid more than juniors (would you rather hire an IQ180 noob who knows nothing about the problem, or an IQ120 worker with 20 years of relevant experience?).
But I'm getting pedantically wound up about this minor nit: both you and beachstartup gave examples of interview questions that are tests of memory, and framed them as tests of problem-solving. If problem-solving is the thing you want to test, those are terrible interview questions for that particular purpose.
well yeah, it's just one question. programming and devops proof is in the pudding. we just ask for code samples and a walkthrough, and go with our gut. maybe a few technical procedure questions.
in my experience it's the other things that will make or break an employee, like whether or not they have an actual work ethic, or is a closet drug addict, or gets too drunk and touches women inappropriately at company events.
these are things you can't test for in an interview or background check, and i find it strange that nobody ever mentions this kind of stuff because personal problems are the most common kind we run into. it's rare to hire someone totally incompetent if you yourself have extensive experience in the work you're hiring them for.
I think that's actually a really good question. It shows deep knowledge and understanding of everything that is happening during a user interaction which is essential knowledge for a webdev. Plenty of "front end developers" have no clue what an HTTP request is.
Nobody was discussing how a keyboard works, but how the web works after you press return on the keyboard. And it's sad that too many web developers in general[1] seem to have the weakest understanding of such basic principles.
[1] super-anecdotal self-selected data points from hiring and conversations
If any front-end developers do want to learn more about Internet/browser networking, I'd highly recommend the book High Performance Browser Networking by Ilya Gregorik. It looks like there's even a free version now available online:
i.e., "a customer reports his website is running too slow. describe how you would identify and solve the problem."
it's a good sign when they start asking you follow-up questions, like "is it load balanced? is there a database?". it's a bad sign when they say, "just restart the server".