181–190 of 238 posts
The only time it made sense is when I was coming in to interview for a lead/manager role. Even then we were (the two interviewers and me) were just walking through architecture level stuff.
My hiring philosophy was to bring in contract to perm w/ 60 day contracts. If the programmer could not provide value we just let the contract expire. Otherwise, there was no way to screen out bullshitters.
I've been paid to write code for 20 years or so and can't remember any of those friggin algorithms. Being able to understand a problem enough to successfully google an answer is the most valuable skill for a programmer.
How do you know the answer you find is a good one? Say you think you need a binary tree, so you can get Log(n) lookup, you look it up, implement it, it works, great. Not bad. Then a lady comes along who actually understands the problem domain, and knows that cache locality will be a big win in this case, and she uses a sorted array with a binary search. Latency is cut in half and the company makes a brazillon dollars…
It only makes sense if the interview process followed the same pattern in those days. The difference is there were not much information to remember, most probably if you knew few data structures and algorithms that was enough.
I feel the tech interview process, like so many other things, is still stuck in the past. Seems that the monks are still tying the cat to the tree without knowing why. Everyone seems unhappy about this but nothing changes.
I actively interviewed job candidates while my wife went through her licensing process to be a doctor. A doctor's job interview spends no time making sure that a doctor is competent. Why? Because the licensing process does that. The most frustrating part of interviewing a software engineer job candidate is that a degree doesn't show that the candidate is competent. Thus, we need to waste our time on imperfect ways to…
Great description of the problem. Licensing is going to be difficult in quickly changing fields.
> The process “freezes out many of the people who are underrepresented in the software development field,” Larson wrote. “If you’re busy working and raising kids, you want to spend as much of your scarce time as possible learning to code — not performing rote memorization that won’t matter once you start your job.” I'm not sure I buy this argument. If you have one candidate who has seen all of this stuff before and c…
If you have one candidate who has seen all of this stuff before and can use it directly from memory, and another candidate who has been busy raising kids and has never seen this stuff before, who do you want to hire, all else being equal? The one who's raised kids† obviously. As that's approximately 3-4 orders of magnitude more difficult -- and indicative of not only of general character (by itself hugely important),…
Every parent I know is a "great mom or dad" simply because you're not allowed to say people aren't great parents unless they are truly bad.
> The process “freezes out many of the people who are underrepresented in the software development field,” Larson wrote. “If you’re busy working and raising kids, you want to spend as much of your scarce time as possible learning to code — not performing rote memorization that won’t matter once you start your job.” I'm not sure I buy this argument. If you have one candidate who has seen all of this stuff before and c…
If you have one candidate who has seen all of this stuff before and can use it directly from memory, and another candidate who has been busy raising kids and has never seen this stuff before, who do you want to hire, all else being equal? The one who's raised kids† obviously. As that's approximately 3-4 orders of magnitude more difficult -- and indicative of not only of general character (by itself hugely important),…
Every parent I know is a "great mom or dad" simply because you're not allowed to say people aren't great parents unless they are truly bad.
> The process “freezes out many of the people who are underrepresented in the software development field,” Larson wrote. “If you’re busy working and raising kids, you want to spend as much of your scarce time as possible learning to code — not performing rote memorization that won’t matter once you start your job.” I'm not sure I buy this argument. If you have one candidate who has seen all of this stuff before and c…
Your argument is invalid.
The whole point of whiteboard coding is that candidates are given a small problem/spec, and to solve it using any language/psuedocode/algorithm they want. The fact that you can ace a whiteboard coding interview without knowing anything about input streams, or bubble sort, or np-complete, is the entire rationale behind this interview style. The fact that whiteboard coding interviews are so precisely objective and formulaic makes them so much less prone to bias, as compared to bullshit interviews where you're asked to reminisce on past projects and your greatest weaknesses. Almost every tweet shown in the article only succeeds in validating the whiteboard coding interview.
So this makes me think: Has anyone here, when presented with a whiteboard problem, tried to google that problem (or algorithm) during the interview? I'm generally not a fan of whiteboard problems because: 1) They don't test what I most care about (architectural things) 2) Why not just pull up a laptop and go at it? but one thing I'd say in defense of them: Thinking through a problem on a whiteboard is a valuable skil…