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

31–40 of 129 posts

Re: How I Interview

#31

Post by collyw »

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.

Re: How I Interview

#32

Post by Yen »

Am 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-rigorous pseudocode expression of an idea.

I think, "if done correctly", whiteboard coding is a good filter for those who can think algorithmically, who can catch the bugs that aren't typos, but incorrect assumptions.

That said, that sort of mindset may not be what you need for your role. Need to consider that.

---

Tangentially, one of the better technical interview experiences I've had involved chatting for a while, the interviewer describing an actual problem they'd had (relevant to the role and the company's product), and discussing my approach to the problem. (and passing or failing the interview wasn't dependent on using the exact same approach...)

Re: How I Interview

#33

Post by collyw »

infraruby wrote: post #28
freework wrote: post #27

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. 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 to emulate it in some way.

Re: How I Interview

#34

Post by bradlys »

> "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 to work at a place that's so great that I'd be there for several years but that's hard to imagine. Most companies I've interviewed with don't exist in 3 years, let alone 'several' (7+).

Re: How I Interview

#35

Post by [deleted] »

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…

[deleted]

Re: How I Interview

#36

Post by infraruby »

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…

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

Re: How I Interview

#37

Post by greggyb »

bradlys wrote: post #34

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

Re: How I Interview

#38

Post by collyw »

infraruby wrote: post #36
collyw wrote: post #33

Earlier quoted context omitted.

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…

> 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 with what I said (at least to some degree), but still asking for something anyway.

Re: How I Interview

#39

Post by invalidfunction »

ryandrake wrote: post #11

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…

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.

Re: How I Interview

#40

Post by [deleted] »

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,…

[deleted]
Post reply on HN