Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I Interview

rkoutnik.com

Post reply on HN
Print view View original

41–50 of 129 posts

Re: How I Interview

#41

Post by yareally »

vdnkh wrote: post #5

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…

Sounds like you dodged a bullet working for them. Personally, I would avoid any company that forces you to use a specific type of computer/os without a good reason (such as iOS development or Windows specific). Good companies will let developers work in what makes them most comfortable, whether that's *nix, windows or OSX.

Re: How I Interview

#42

Post by phamilton »

lilcarlyung wrote: post #6

Would be funny to come into an interview as the candidate and give the employer pre-packaged tasks to complete to evaluate them on, to decide if I as the candidate actually want to work there.

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.

Re: How I Interview

#43

Post by gkop »

Do JavaScript experts consider JSBin a decent environment for this task? JavaScript is a bit verbose and I would resent simply the aspect of having to write a substantial amount of JavaScript without autocomplete.

I just played with JSBin and it doesn't have autocomplete out of the box.

Edit: whoa I just re-read the OP and found this

> Most [candidates] tend to use the laptop & JSBin provided

That's super hypocritical, OP (see your paragraph headed "Comfortable situation")! If you "provide" them with an environment of course most are going to use what you provide since that is what you are suggesting. So now you're filtering for people for whom that laptop model and the JSBin tool are familiar and comfortable.

Or in the case of those that reject your environment and choose their own familiar and comfortable laptop and editor, you are filtering for those with the self-confidence to reject the suggestion of the interviewer, which doesn't really help with your stated goal.

It's a shame because I like some of your other points :/

Re: How I Interview

#44

Post by sheepmullet »

i_s wrote: post #4
padolsey wrote: post #2

This methodology may correctly filter the candidates the author is seeking, but if this made up the bulk of any interview I attended, it would probably turn me off the role. FWIW, when I attend an interview, as either party, I want to have a discussion, a bit of back-and-forth, and crucially to determine if it's likely we'd be able to get on, day to day. Coding competency is not the only important thing. And anyway,…

> Being given a pre-packaged task to complete feels very procedural and bland... This part is important: > Having a consistent test also allows me to compare candidates easily and without bias. Also, I think most people would care more about the content of the exercise, rather than whether it is prepackaged or not.

> This part is important: > Having a consistent test also allows me to compare candidates easily and without bias.

No, it isn't. The person who performs best on the test is often not the person who will perform the best on the job.

Tests like these should always be pass/fail.

Re: How I Interview

#45

Post by jarjoura »

I've been giving interviews for almost a decade now and I've both tried and seen many different approaches. Yet, I think the MOST important part of the 45-60 minute time slot I get with a candidate (or future coworker), is the conversation.

1) I want to see passion for solving problems in the space. There are endless problems to solve in the industry, but I want to know they'll be excited to work on my team's problems.

2) What are they doing here? Was this a numbers game (interview at a ton of different places in hopes of getting one good offer)? Were they recruited or did they actively seek this position out?

I've seen candidates where in one interview I have to throw multiple problems at them, because they think about it for 30 seconds and then come up with a correct solution and quickly write it out on the board. I'll usually run out of questions for these candidates.

Ultimately, white-board coding works well for some, and is a complete disaster for others. Yet I don't believe it means white-board interviews should be thrown away in an effort to be "fair." I just think as engineers, if we really want to land a position at a Google, Facebook, or Uber, etc, is it too much to ask that we study up on our algorithms?

Re: How I Interview

#46

Post by invalidOrTaken »

collyw wrote: post #33
infraruby wrote: post #28

Earlier quoted context omitted.

> 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...

I can see this being misinterperted badly in the field of software engineering (it doesn't seem specific to software) as it says work sample tests are best, yet most software is large scale, and takes time to develop and ought to involve planning, architecture, coding, technology selection, testing. So most "sample work" for an interview will actually be nothing like that but a short rushed version that is supposed t…

A work sample test for a developer position might be: Here is the name of a niche board game. Over the next day, find the manual. Tomorrow, come in and play a round with me.

Half of what developers do is master arcane rules from obscure texts. Is this not, in fact, a work sample?

Re: How I Interview

#47

Post by infraruby »

collyw wrote: post #38
infraruby wrote: post #36

Earlier quoted context omitted.

> I can see this being misinterperted badly in the field of software engineering (it doesn't seem specific to software) Would you prefer Google's take on it? http://www.wired.com/2015/04/hire-like-google/ > So most "sample work" for an interview will actually be nothing like that but a short rushed version that is supposed to emulate it in some way. Yes, that's the idea! And it works.

From the article : "but for many jobs there are too many variables involved day‑to‑day to allow the construction of a representative work sample. All our technical hires, whether in engineering or product management, go through a work sample test of sorts, where they are asked to solve engineering problems during the interview." Plus a number of other things according to the article. Sounds like they are agreeing wit…

> Plus a number of other things according to the article.

Yes, combining methods works even better! It's far from saying that the best way is "to just talk to them".

Re: How I Interview

#48

Post by tokenadult »

I wonder if the OP has ever read any actual research on effective hiring practices. I have a FAQ for that.[1] The short answer that research gives is to set up an actual work-sample test for the job in question. The longer answer is to add in a VALIDATED test of the worker's general cognitive ability. But if that kind of test isn't validated, the employer can be subject to legal consequences in the United States if the test has "adverse impact" on protected minority groups. Rather than just making up hiring procedures, companies ought to do research on what works for finding better workers and what is not legally risky for the company.

[1] https://news.ycombinator.com/item?id=4613543

Re: How I Interview

#49

Post by acjohnson55 »

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 this at my last job on the topic: http://www.huffingtonpost.com/alanjohnson/were-hiring-engine...

Re: How I Interview

#50

Post by autarch »

collyw wrote: post #31
autarch wrote: 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…

Homework exercises are a large burden on the candidate, so expect to half your pool for that reason alone. I only do about half or less of these, as most are crappy an unrelated to the job. I prefer to plan and do things thoroughly, not rush a solution out in a couple of hours. And to be honest asking for more than a couple of hours is more than you should be asking unless you are willing to pay.

We've had a pretty good response rate when asking people to do this. Of course, I totally understand why someone would say no. I'd love to find a better way to evaluate someone's skills, but absent a good public FOSS portofolio, what are my options?
Post reply on HN