I'm a Software Engineer, have been passionate about computers my entire life, and I've never once played Minesweeper.
I actually have no idea how.
How I Interview
51–60 of 129 posts
Re: How I Interview
#52I 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. You're wrong: http://www.ioatwork.com/selection-methods-almost-a-century-o...
IQ tests? Sounds too good to be true.
Re: How I Interview
#53So, like, my own personal experience...
A couple of years ago I applied for a certain company that this year turned out to be a unicorn.
The automated reply said to build a Minesweeper. So I did. It took a several hours to get into a shape that is playable. Then it took several days to polish it into app store quality.
You can play here: http://www.ronilan.com/bugsweeper/
Download here: http://www.appstore.com/bugsweepergame
And copy as much as you want from here: http://www.ronilan.com/bugsweeper/js/bugsweeper.js
If you are wondering how it went from there, they were "evasive". Then I got a softball "center a div" interview with one of their front-ends. Then I got a polite no thanks from the recruiter.
And that's all I have to say about it.
Re: How I Interview
#54Uggh, been interviewing this month and it has been mostly awful. From "who was your worst boss/what is your worst quality" to "solve this problem with us watching, clock ticking, and a $150k on the line."
Also, the only profession (I know of) where twenty years experience is considered a detriment. Perhaps fashion modeling is another? ;)
Re: How I Interview
#55What? "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…
It's minesweeper, not an enterprise storage server. Spending 3 hours planning minesweeper would be insane. Heck even planning for more than 20 minutes, in my personal opinion, is overkill. You should be able to at least get started before the 30 minute mark and if you spent half the time planning should be close to being done before the end of the hour. At the end of the hour, just explain what you have left to do.
I don't know how to play minesweeper, so how on earth am I supposed to solve it in 30 minutes? Looking up the rule in 30 minutes? I don't know how to play Sudoku either. DO you know how to play Go? Can you implement that in 30 minuets? Do you know how to play Mofoka? Of course you don't know Mofoka I just made it up. Please think about how ridiculous it is to ask someone to implement a game in an interview.
Re: How I Interview
#56My personal, preferred way to interview data scientists (besides administering a work sample test) is to talk to them about the most challenging effort they've been a part of. Start with understanding the overall business context and the technical infrastructure they were working with, and gradually follow through until you understand the key ideas that underpin the innovation.
The key is to get them to explain things until you understand the essence at a foundational level - hopefully you understand what combination of the notions of statistical independence / power / dimensionality / algorithmic complexity has birthed novel system or algorithm they built.
The process selects for people who have a) already built something substantial, and b) have the communication skills to explain it.
Re: How I Interview
#57I did the challenge and it was a fun endeavor. I'm mainly a C# dev. I dabble in AngularJS at work but don't consider myself a pro. I'd never tried drawing to the canvas so this seemed like a good challenge.
I managed to get something fairly workable, albeit ugly code-wise, banged out in 1hr. If you reviewed my google searches, you would see that:
- I didn't know how to init a 2d array in javascript
- I didn't know that the things on the canvas couldn't be accessed directly for click handlers
- I cheated on the solution for finding neighbors because I was running out of time
*edit formatting
Re: How I Interview
#58So, like, my own personal experience... A couple of years ago I applied for a certain company that this year turned out to be a unicorn. The automated reply said to build a Minesweeper. So I did. It took a several hours to get into a shape that is playable. Then it took several days to polish it into app store quality. You can play here: http://www.ronilan.com/bugsweeper/ Download here: http://www.appstore.com/bugswe…
Automated response questions are so disrespectful. "We won't take the time to see if we're in any way interested, and won't unless you devote your own time."
Re: How I Interview
#59Am I the only one who, when being interviewed, doesn't mind whiteboard coding? At interviews where I've later been given an offer, it's usually a relatively small algorithmic design challenge, where the specifics don't matter, just the pseudocode. In interviews I've given involving whiteboard programming, I've always emphasized that it doesn't have to be valid or even semi-valid code for any language, just a semi-rig…
> Am I the only one who, when being interviewed, doesn't mind whiteboard coding?
I'm sure you're not, but my experience is completely opposite of yours. I'm still relatively early on in my career (I've had 3 software jobs, but have grown up coding since I was 12), but every job I scored was one that didn't use a whiteboard/paper problem during an interview.
I got a lot better at whiteboards with practice; but early on, every whiteboard problem I received resulted in me blanking on even the most basic concepts. I would have no idea how to solve problems on a whiteboard that I explicitly solved in a codebase the week prior. Then I'd step out of the interview and the solution would just hit me.
It's like state-dependent learning, in a way. As I got tested more on whiteboard coding, I figured out that whole problem-solving process better, and I do pretty well on them now. Still, I continue complain about those problems. They feel like a completely foreign, perpendicular challenge compared to having a discussion, answering questions, or writing code to solve the same problem. It's not a skill I've ever used outside of interviews, nor is it a situation that has ever been simulated at any workplace I've been at.
There's nothing wrong with evaluating a candidate's whiteboard presentation skills. If the goal is specifically to evaluate technical or algorithmic knowledge, it's worth taking into account that testing for that knowledge on a whiteboard can introduce a side-effect that bottlenecks the candidate's ability to present their answer.
Re: How I Interview
#60> "Candidates are also reviewing a company. They'll be dedicating several years of their lives to this workplace and will be looking at the interview filter to see what it takes to get in." Really? I barely know anyone who works for several years at any place. I'm looking at whether I can tolerate it for six months. That's only so I can take a job search break for a few months before hitting the grind again. I'd love…
This is a very small niche that you live in. I can tell you that a candidate with 7+ 6 month engagements would be unlikely to get a position at my current company (mid-sized business intelligence consultancy), and simply wouldn't be considered at my last company (old school enterprise environment). The startup scene is not representative of the job market for the majority of people.
>The startup scene is not representative of the job market for the majority of people.
On that note, I'm surprised that startups would hire frequent-short-stint employees. The startup I work at has a great proportion of people who have stuck around since the early days; yet I have worked (and interviewed) at large companies where everyone bails within a couple of years max. I don't know what the West Coast "scene" is like, so my company probably doesn't resemble SV startups, but the pay is great, the people are smart and passionate, and the businesses is hitting all of its goals, so I'm not complaining.