I have a degree in computer science, and I have been a professional full-stack developer for almost 9 years. I could probably not solve the problem in your first link in 25 minutes. I know exactly how I would solve it, conceptually and what data structures I would use, but I am not sure I'd get the adjacent mines part correct on the first attempt.
Then again, this is nothing like the type of problems I work on a daily basis.
(Not GP) After looking at the page and the problem description, I agree. The time limit of 25 minutes is way too short for this considering that the person may already be stressed and find it difficult to understand that big wall of requirements and implement it in this time span. It doesn’t matter if one is a self taught programmer or has a CS degree.
I don’t know if they’re looking for superheroes or people who can put in the work.
If the GP is reading this, I’d suggest increasing the timer a lot more (like one hour, what’s the big deal anyway?) and splitting the requirement and steps into smaller chunks. The “optimize for speed” remark in the instructions is also a bit confusing.
It's a bit off the main topic of this thread, but the problem isn't designed to be finished in time. From the page:
> Very few people will finish the full problem. You do not need to complete every step to pass our interview.
A problem that an average candidate completes doesn't have a lot of differentiating power on the high end, whereas a problem where an OK candidate finishes 2-3 steps and a great one finishes 4-5 carries a lot more information.
I don't think how far a candidate gets on this particular test determines if they're OK or if they're great. I posit that a great one could finish 2-3 steps and an OK one could finish 4-5.
Because like many people have stated, this is just a hand holding test. You're basically seeing if they can code. So you're testing how fast someone can take a list of 5 steps someone else gives you and translate it into code in under 30 minutes.
And I'll tell you, I've never, in my life, worked on code with a series of 5 requirements and submitted it for review after 30 minutes. That would be bonkers, because I'd probably spend at least an hour sussing out all the ambiguities and contradictions.
"Basically seeing if they can code" is the goal, yes.
> I don't think how far a candidate gets on this particular test determines if they're OK or if they're great.
It doesn't with certainty, but measurement of this kind is always subject to some degree of error. The point of interviewing (especially at the early stage where this interview is applied) is signal, not certainty, and we do seem to be picking up on signal:
-- # of steps completed on the coding task is the strongest single signal of success at later final interview rounds. Candidates who have gotten offers (not from us, to be clear, so this is uncorrelated error) average ~1.1 more steps completed on our coding problem than candidates who don't. That's after we filtered a lot of the weaker results out, so it's sampling biased in slower candidates' favor. This is a larger gap between offers and non-offers than any of the other nineteen individual internal scores we record for each interview, iirc.
-- # of steps completed correlates with results on the rest of the interview in a way that is aligned with reasonable psychometric measures of quality, same as most of the other parts of the interview (see e.g. [1]).
If your point here is just that interviews involve somewhat artificial work and are prone to error - well, yes. Everyone involved in testing as a field already knows that and is working around it.
To use your concrete example, creating a problem involving "sussing out all the ambiguities and contradictions" for an hour would be asking a lot more work from candidates. If we did that, I bet we'd have people complaining about the lengthy workload of doing an interview (or simply not doing it, which would be fatal to us as a business). I would also worry that that's a much fuzzier skill to measure, particularly in a cross-organizational way. It's not that, in isolation, you could never create an interview to test ambiguity-resolution, it's that (at least in my judgment), it would be impractical for us to do so given what we are trying to do.
And finally, to this:
> I posit that a great one could finish 2-3 steps and an OK one could finish 4-5.
So as an applicant, I would be left with the nagging feeling that I didn't finish the problem, and knowing myself and seeing the time constraint I choose to avoid those interview processes.
Yeah, I don't think this thread is about the interview process. It's just for the self-taught developers to feel superior. Or maybe I became too cynic, who knows.
I respectfully disagree that this problem needs anywhere close to an hour; and having the problem already broken down into rather simple steps is a significant amount of handholding.
As for being stressed -- if this is too much, how will you do when asked to solve even harder problems with tight schedules and/or demanding customers?
I agree with your assessment of the problem. It’s already been broken out into discrete chunks that are all simply solvable in short order. Even finding neighbor squares is reasonably straightforward (generating all 8 candidates is basically trivial, then pass them through a filter for each of the four edges).
But your take on the stress component of an interview is way off base. There’s a huge difference in having stress on you to deal with other people’s problems vs. your own. An interview candidate may be in financial trouble and may have been struggling for months to find employment in a terrible job market. This is existential stress on a completely different level than a customer wanting a feature yesterday.
I've solved plenty of hard problems at work, but none of them have ever looked like "count the grid squares adjacent to a given grid square while taking the grid's edges into account so the program doesn't blow up because you tried to access an invalid index."
And if I did have to do something like that at work, I promise my manager would give me more than 25 minutes to do it.
sum += (x > 0 && y > 0 && x < x_limit && y < y_limit) ? a[y][x] : 0;
That took less than a minute of thought; or you could use a common technique in image and video processing, which is to make sure that the edges are always present but filled with appropriate values by defining your grid to be slightly bigger than the active area.
I just concentrated on what would be the hardest part, the "edge" cases (literally.) Wrapping that in a loop that goes through the appropriate indices is not much more work. There is a sibling dead comment to mine which has the rest.
> if this is too much, how will you do when asked to solve even harder problems with tight schedules and/or demanding customers?
Isn't the whole reason you are joining a team is so that you have a support network when such situations arise? The period of acting alone to join that team is a temporary aberration and is to be recognized as such.
You may as well be the business selling to those demanding customers if you have what it takes to handle going at it alone. It will be far more profitable. But if you don't have it...
> As for being stressed -- if this is too much, how will you do when asked to solve even harder problems with tight schedules and/or demanding customers?
There's no such single "stress". It's all different. Being yelled at by mom is "stress", and so is being held at gunpoint. Not the same kind of stress.
Making the slightest mistake or wrong impression during an interview pretty much ends it right there and by extension kills your chances of employment. Your entire future career and financial stability for the next 5-10 years hangs in the balance at all times during an interview.
Not comparable in any way to "the customer is being annoying today".
If you just had "implement mine sweeper" sure, but the page does tell you exactly how to implement it so you don't even have to think to solve it. Just write the 5 functions they tell you to write and done, each of those are a few lines.
I just gave it a shot; I would definitely need more than 25 minutes.
> I am not sure I'd get the adjacent mines part correct on the first attempt
Yeah, getting to that point was easy. Solving that problem is where I got stuck. I'm sure I'd get it eventually, but getting to that point and figuring that out in 25 minutes is asking a bit too much.
Perhaps that is suited for candidates with image processing experience, because looking at surrounding pixels is a common pattern in image and video codecs. I suspect APL-family experience/thinking style will also help significantly (if you haven't seen it, I recommend watching this video: http://youtube.com/watch?v=a9xAKttWgP4 )
The floodfill part (the last one), on the other hand, is the one that stands out in difficulty compared to the previous parts.
Really? We had informal flood fill competitions in my high school... If you understand recursion, it's easy. If you don't... there's so many other things than flood fill you just can't do. And the generalization of saying "oh, that's just a work list" is easy and enables even more things.
> Then again, this is nothing like the type of problems I work on a daily basis.
I thought it'd be fun to take a stab at it in Python, which I haven't used in a while, but only barely still remembered that I could accept command-line input with the built in `input` function, something I don't think I ever used after writing my first lines of code 15 years ago. Then I figured I'd use just lists instead of a numpy array but had forgotten that [[0] * 4] * 4 would just create 4 references to the same list. And that pretty much derailed the whole thing for me, even though I was sure I'd get it done in 25 minutes or under :-)
Then again, this is nothing like the type of problems I work on a daily basis.