I was really liking this piece, but one inherent flaw of the example given is that I've already implemented minesweeper in javascript once a couple years ago for a programming challenge, so I'd have a major advantage over most candidates. For example, I immediately recalled I solved the problem of mine placement with a 1 liner like: var cells = ('*'.repeat(mineCount) + ' '.repeat(size - mineCount)).split("").sort(fun…
Correct me if I am wrong, but wont this result in the mines being placed in the front more often than not? sort(function() { return math.rand() - .5; }) doesnt result in a truely random distribution.
What? "Implement as much of Minesweeper as you can in an hour?" If you're going to build something--evens something as simple as Minesweeper, you're still going to need time to plan it out, diagram it, decide which modules call into which other ones, decide on the data structures, etc. Diving right into writing code so you can get _something_ done in an hour is probably the worst strategy if your goal is to do it rig…
I've had folks who just jump into the code without any planning. It usually bites them about 20-30 minutes in. On the other hand, I remember one guy who spent the first 20 minutes planning and only 40 coding and ended up doing better than most. The point here is not "Write as many lines of code as you can". I want the candidate to plan - it's a crucial part of the job. FizzBuzz, sorts and the like don't require much…
I had an interview like this recently. A "live coding" exercise after (in their words) two excellent phone screens. The test was to implement a class which would be run through a bunch of unit tests. Simple right? It turned out to be a disaster. First was the choice of language. They offered to take it in JS, Ruby, Python, or Java. I'm a .NET developer whose competent with JS, but I really could be better at it. I as…
> "I asked to take it in C# but they refused and said it's not about specific language knowledge."
So.. "This isnt about a specific language, but you must use the ones we tell you!"
I get that. I just would rather not feel like a monkey being prodded whenever I attend an interview. An interview being repeatable (for comparative purposes) brings no value to the candidate.
It does if the candidate is something that the interviewer might be biased against (race, gender, opinions on Star Wars). Avoiding bias in interviews helps everyone except those who rely on irrelevant qualities to get jobs.
Maybe, but I feel that the answer to such biases is to introspect and understand your potential prejudgements, and then not let them specifically sway you. Anyway, the accepted alternative, an entirely meritocratic process, is fraught with issues too, as the playing field is inegalitarian to begin with -- so those candidates who might be the victims of unfair biases could already be at a disadvantage since they might not have received the privileges that preempt meritocratic success. It is assumed that relying totally on a candidate's coding ability somehow avoids the issue of bias and works to mend our diversity issues in this sector, but it actually merely plays into the entrenched state of things. I don't have a solution, but this entire problem-set is certainly deserving of more nuanced thought.
I was really liking this piece, but one inherent flaw of the example given is that I've already implemented minesweeper in javascript once a couple years ago for a programming challenge, so I'd have a major advantage over most candidates. For example, I immediately recalled I solved the problem of mine placement with a 1 liner like: var cells = ('*'.repeat(mineCount) + ' '.repeat(size - mineCount)).split("").sort(fun…
Correct me if I am wrong, but wont this result in the mines being placed in the front more often than not? sort(function() { return math.rand() - .5; }) doesnt result in a truely random distribution.
> doesnt result in a truely random distribution.
It evenly distributes over 0-1. Removing .5, just distributes it evenly between -0.5 and +0.5.
Sort basically says >0, the first option should come first and if I believe this still maintains a random distribution and is quite a tidy solution. Thoughts?
I had an interview like this recently. A "live coding" exercise after (in their words) two excellent phone screens. The test was to implement a class which would be run through a bunch of unit tests. Simple right? It turned out to be a disaster. First was the choice of language. They offered to take it in JS, Ruby, Python, or Java. I'm a .NET developer whose competent with JS, but I really could be better at it. I as…
I explicitly and repeatedly told a recruiter and the hiring manager from a (unicorn) YC startup with a large logistics component that, while I am a data scientist, I don't do OR / stochastic processes. I took a single class on them over a decade ago and that's about it. They repeatedly assured me they also needed someone who builds classifiers/models user behavior. Guess what the the in-person interview was about...
I still think the best way to interview a programmer is to just talk to them. Ask them about their experiences. I've known a bunch of programmers in my time, and I feel I can tell if someone is the real deal within a few minutes of them speaking.
I'm happily employed at the moment (knock on wood) but when that day comes where I have to go back out an interview, I don't plan on wasting any time doing these kinds of interviews where they make you spend hours doing some kind of programming challenge. To me it's an indicator that the company doesn't have anybody knowledgeable to actually pick out the best programmers.
I still think the best way to interview a programmer is to just talk to them. Ask them about their experiences. I've known a bunch of programmers in my time, and I feel I can tell if someone is the real deal within a few minutes of them speaking. I'm happily employed at the moment (knock on wood) but when that day comes where I have to go back out an interview, I don't plan on wasting any time doing these kinds of in…
> I still think the best way to interview a programmer is to just talk to them.
I still think the best way to interview a programmer is to just talk to them. Ask them about their experiences. I've known a bunch of programmers in my time, and I feel I can tell if someone is the real deal within a few minutes of them speaking. I'm happily employed at the moment (knock on wood) but when that day comes where I have to go back out an interview, I don't plan on wasting any time doing these kinds of in…
I completely agree. Talk to me about some good times and some bad times. Talk to me about hindsight and some of the crazy ideas you have bouncing around in your head.
What? "Implement as much of Minesweeper as you can in an hour?" If you're going to build something--evens something as simple as Minesweeper, you're still going to need time to plan it out, diagram it, decide which modules call into which other ones, decide on the data structures, etc. Diving right into writing code so you can get _something_ done in an hour is probably the worst strategy if your goal is to do it rig…