Live data from Hacker News

How I Interview

rkoutnik.com

101–110 of 129 posts

Re: How I Interview

#101

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 decided to have a go at this, even though I am at best a JavaScript dabbler.

I did plan...but if you were watching me you would not have seen me planning.

I decided right away that my display was going to be a table with one table cell per Minesweeper cell, with the table cell's ID of the form "X_Y" where X and Y are the coordinates of the corresponding Minesweeper cell. I did the rest of my planning while getting that HTML written (first in vim, and then when that was going too slow even with macro assistance by writing a little Perl script to generate the HTML).

I was not able to do it in an hour. At the end of one hour, I had everything for a rudimentary Minesweeper coded, but had a bug in the code that reveals the cells around a clicked empty cell, and it took another 20 minutes to find and fix that.

Here is what I came up with: https://github.com/tzs/interview_minesweeper

The initial commit was made at the one hour point, so that would have been what I would have turned in during an interview.

Re: How I Interview

#102
post #77

Earlier quoted context omitted.

I've been toying with the idea of asking for a reverse interview. I get to ask about the challenges they've solved in great detail and how they dealt with potential and actual issues. They get to answer and decide to I know what I'm talking about.

Is this not the whole point of the interview for you now anyway? For me, if I go in somewhere and get grilled for X hours and they deprive me of a chance to ask about certain aspects of the company, you can guarantee u won't take the job.

That's what I'm counting on. Most startups are sufficiently desperate for hiring that you can ask for things like "I'd like to grab coffee with the CTO" and they will do it (that seems trivial at a 10 person company, but I've heard it happen at 100+ person teams).

Where I am right now, I'm pretty happy just turning down the interview if I don't oblige.

Re: How I Interview

#103
post #62

I have decided that I will no longer take technical interviews. I have 25 years of software development under my belt, I published a book, spoke at various conferences in Europe, have a Github profile (admittedly not very lively), worked for well-established enterprises and have great references. Why shall I still prove myself? If I was a senior lawyer or an architect joining a new studio, I strongly doubt I would ha…

Your approach seems sensible as a freelancer. Hope it works out for you! But I don't think it would work for someone who's full-time employed looking for another full-time employer:

1. People can't just take two weeks off to go code for another company.

2. With so many other candidates out there, a company is typically not going to bother with an "eccentric" who refuses to interview. (not saying you are eccentric, just that's how you'll appear next to the other 100 traditional "interview me I need a job!" applicants)

I've seen #2 play out in real life. Company interviewed a guy who refused to do any code on a whiteboard, even simple fizzbuzzy stuff, pointing to his multi-decade resume full of big name companies and high-profile projects as proof that he's good. The company's response was basically "OK, there's the door".

Re: How I Interview

#104
post #65

I live in Switzerland and I used to code for a living. As an external, I hire engineers for different startups in Zurich. As I got deeper into IT-recruiting, I realised that candidate filtering at the top of the funnel is fundamentally broken. The market for software engineers is different from the market for - let's say - actors. Especially for senior developers there is way more demand than there is supply. This ha…

> The market for software engineers is different from the market for - let's say - actors. Especially for senior developers there is way more demand than there is supply.

The "undersupply of engineers" meme again! This is a simplification. Supply and demand are measured at a given price. There may be way more demand than supply at one price (salary), but supply and demand is balanced at a more appropriate salary.

Re: How I Interview

#105
post #13

Where I work we do something similar but it's a "homework" question we give to people who pass our initial resume screen ( https://github.com/maxmind/dev-hire-homework ). We tell them not to spend more than 1-2 hours on it. We decide whether or not to interview them based on the quality of the code they produce. In the interview we ask things like: * what is OO and how is it different from procedural programming? (hi…

The homework question is great. But how could a candidate's answers to those interview questions be indicative of anything really?

Re: How I Interview

#106

Uggh, 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? ;)

It's odd, isn't it? Twenty years of experience is considered good, but twenty extra years of age is considered bad. This actually goes a long way to explaining why interviews are such an odd experience - companies recruit for experience (must have launched successfully with experience scaling), and then testing for exam-ready knowledge of second year algorithms and data structures. I suppose another way to put it is that employers would like people with 20 years of experience who graduated from college last week.

Re: How I Interview

#107

As a counterpoint, I'm fairly confident it's possible to hire engineers without seeing the code anything at all. I'm not an expert, but I do know that I've never felt like a homework/sample code/whiteboard exercise I've done has borne any real resemblance to the work I do. I'm generally a fan of getting a candidate to tell me about aspects of their previous work that relate to the skills the job requires. I wrote thi…

I've never been required to provide a code sample for a job interview nor have I ever asked for one. I've had pretty good luck sussing out who knows what they're doing based on their ability to talk in detail about what work they've been doing.

Re: How I Interview

#108
post #62

I have decided that I will no longer take technical interviews. I have 25 years of software development under my belt, I published a book, spoke at various conferences in Europe, have a Github profile (admittedly not very lively), worked for well-established enterprises and have great references. Why shall I still prove myself? If I was a senior lawyer or an architect joining a new studio, I strongly doubt I would ha…

[deleted]

Re: How I Interview

#109
post #80

Earlier quoted context omitted.

> Why shall I still prove myself? Because we see candidates claiming that level of experience that cannot construct a simple for loop.

Well claiming is a very far galaxy from "demonstrating". What about references? What about networking? What about published books and papers. This stuff is very hard to make up, especially references.

I think you'd be surprised that it's actually a lot easier than one might think.

Unless they are references from people who those involved with hiring personally know.

Re: How I Interview

#110

Interesting points. Like the idea of the giving a developer actual development tasks. This is how I interview - We have a bitbucket set up with a project very similar to our current site. We simply ask everyone who applies to get the code from Bitbucket and install it locally. And then fix a simple bug. Most developers who are well versed in the basics are able to install the code in 2-4 hours. People new to somethin…

I love the bug fixing stuff especially if I'm allowed to re-architect your stuff so that it's less prone to bugs to start with ;)

Thats the trick to guarantee a job
Post reply on HN