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

Ask HN: What should an ideal developer interview process look like?

news.ycombinator.com

Post reply on HN
Print view View original

261–270 of 289 posts

Re: Ask HN: What should an ideal developer interview process look like?

#261

Post by ArchTypical »

pytester wrote: post #251
ArchTypical wrote: post #245

Earlier quoted context omitted.

> Exercises that try to mimic what the developer would be doing in the actual job as closely as possible. This one is critical. (the following is just inspired by your bullet) The job of a developer consists of problem solving something they have never encountered before (under some pressure), communicating to other developers, and demonstrating knowledge in various combinations and amounts over time. Startup develop…

>Talking through a few whiteboard problems and talking about tools they have used (why and how) are sufficient. I've done interviews with a whiteboarding "tell me about stuff you've worked on" component followed by a test. It thought it gave a weak signal about the skills of the candidate. I canned it eventually because the test gave a very strong signal and it wasn't telling me anything the test didn't. >Interviews…

> https://medium.com/@alexgolec/google-interview-questions-dec...

I'm really frustrated when these kind of problems are presented as "whiteboard" problems. It's not constructive and discouraging to potential employees. When something as simple as "implement X without using Y" or "fix this program with pseudocode" are practically useful experiments and more indicative of what developers are doing to be doing ALONE every day. If there's inefficiency, code reviews and planning and integration all reveal that and you can pull in specialized resources if you really need it.

Re: Ask HN: What should an ideal developer interview process look like?

#262

Post by justfor1comment »

A friend of mine is a UI designer and I really like how she gets interviewed. Her first interview during an onsite is to give a presentation about herself and her prior work. The audience are the 3-4 designers who will be interviewing her that day. This helps her set the tone of the future interviews and also gives an opportunity to show case her best work. We never get this chance during software interviews. I feel software interviews are like QA testing. The interviewers will each enter edge cases and see if you break under any one of them. Your resume might as well be shredded by the recruiter, cause it never gets read by the interviewers. You never get to paint a fair picture of yourself and that is quite frustrating.

Re: Ask HN: What should an ideal developer interview process look like?

#263

Post by pmiller2 »

ashelmire wrote: post #229
pmiller2 wrote: post #55

Earlier quoted context omitted.

How is that any different from taking a whole day to do a normal onsite interview? Doesn’t that also favor those with the ability to take a day to jump through hoops?

"Normal" for who? It's normal for fresh graduates interviewing at the biggest tech companies, but that's not normal anywhere else in the world or for other jobs.

Normal for anyone interviewing as a software engineer in the Bay Area.

Re: Ask HN: What should an ideal developer interview process look like?

#264

Post by l0b0 »

maccard wrote: post #86
l0b0 wrote: post #36

I would give them opportunities to show their skills at real-world tasks: - Version control. Given a terminal (or Explorer with TortoiseSomething) and an existing project, make some simple changes and commit. - Testing. Given a simple piece of code, its tests and either a bug report or feature request, explain at least in high level terms how to move forward. - Code review. Give constructive feedback on how to improv…

> Version control. Given a terminal (or Explorer with TortoiseSomething) and an existing project, make some simple changes and commit. Does this really tell you anything about a candidate? If you sat me down in front of a terminal and said "here's a git shell, make a change and commit it" I'd fail the test immediately. I've used perforce for the last 9 years, and the terms are not the same, and the commands are _not_…

I specified "TortoiseSomething" rather than "TortoiseGit" because I specifically did not expect the developer to be familiar with all VCSes. This needs to be agreed upon in advance - it shouldn't be hard to create an environment for whichever VCS the candidate is familiar with.

Re: Ask HN: What should an ideal developer interview process look like?

#265

Post by andrei_says_ »

weliketocode wrote: post #177

Many people here will disagree with what I'm about to say, but if you're going to give a coding challenge... I like hackerrank/codility style coding challenges. gasp They're timed. They're run against a standardized test suite. And they have support for many languages. It's really unfortunate the number of companies that give custom take home coding challenges that run the gamut. The problems with which are manifold:…

Timing a code challenge is a bit like chess boxing. Increased cortisol levels diminish or shut down the reasoning function of the brain, so expecting someone to code fast under the threat to lose a potential employnentbopportunity is not exactly productive.

Re: Ask HN: What should an ideal developer interview process look like?

#266

Post by flukus »

maccard wrote: post #144
jgforbes wrote: post #127

Earlier quoted context omitted.

I also balked at it, but for the opposite reason. Everyone should be able to sit down to a terminal, make a change to a repository, and commit it. I mean even if you don't know the command (or they are using a different version control system then you are used to) you can always check the help or man page. It's still a trivial task.

> Everyone should be able to sit down to a terminal, make a change to a repository, and commit it Disagree - You're testing can someone use the basics of git in a terminal. > you can always check the help or man page. Assuming you know how to do that, and what you're looking at. Say I'm sat down in front of a terminal, and I'm told "here's a terminal, make a change and commit it" I type in "git", and I get: "usage: g…

> I type in "git", and I get: "usage: git" - If you're used to using shell tools, then sure you can make sense of it, If you're not, then you're done.

That's part of the test, to see if they're familiar with the command line and if they know how to open the man page. It's trying to weed out the people that can only work in the confines of an IDE and gui tools. That said I wouldn't expect anyone to know git from the man page, I would however expect anyone for a senior role to be familiar with what is a de-facto industry standard.

And source control in general is a great topic for interviews on both sides. Many devs (and companies) don't know what a branch is or what you'd use one for. Many companies make it hard/impossible to create feature branches, either by policy or crazy mono-repo stuff. Even their choice of SCM says a great deal about them, I'd avoid anyone that uses clear case or TFS.

Re: Ask HN: What should an ideal developer interview process look like?

#267

Post by chillacy »

lawnchair_larry wrote: post #233
chillacy wrote: post #53

Earlier quoted context omitted.

How has that been working out for you? I used to think the same and I'd ask a "programming passion question" right before a simple coding question, and then I'd run into these amazing bullshitters who could talk shop but couldn't write fizzbuzz. But they'd come up with a bunch of excuses as they were writing the code as to why ("oh my company uses this other framework so I forgot how to write a for loop"). So sadly I…

Nobody who can go into that level of detail doesn’t know what a for loop is.

It seems you're doubting my story. Maybe you think my threshold for "that level of detail" isn't sufficient, or whatever candidate sourcing we use doesn't filter these people out.

Re: Ask HN: What should an ideal developer interview process look like?

#268

Post by chillacy »

thaumasiotes wrote: post #60
chillacy wrote: post #51

Earlier quoted context omitted.

So instead of giving you a 6 month trial run followed by employment they should give you a permanently temporary gig? Because a job where they hire and fire freely sounds a lot like how companies treat contractors.

That's already the way almost all jobs are. Being "hired" isn't a protection for your job. It just means you're getting automatic tax withholding. I was a formal full-time employee at NCC Group until just a month ago, when they fired me with no warning, no explanation, and no severance.

At my company employment is also at will so they can terminate, but they try very hard not to. In practice contractors are let go much more frequently than employees, and when employees are let go they tend to get a soft landing. But maybe my job is the exception.

Re: Ask HN: What should an ideal developer interview process look like?

#269

Post by chillacy »

oceanghost wrote: post #257
chillacy wrote: post #51

Earlier quoted context omitted.

So instead of giving you a 6 month trial run followed by employment they should give you a permanently temporary gig? Because a job where they hire and fire freely sounds a lot like how companies treat contractors.

I was, of course, using the story to illustrate the absurdity of the overall situation. I don't want to leave a secure job for an insecure situation because they're difficult to find. They won't consider a direct hire for a "perfect candidate" -- proving my fears. My point which perhaps I should have been made more clearly is that they're asking me to leave a direct hire situation for a temp job. They're asking me fo…

I see, thank you for explaining. It just seemed odd that you yourself sought a secure situation but in you also said "Culturally, we should hire and fire more freely" which to me sounded like we shouldn't have these secure situations at all.

Re: Ask HN: What should an ideal developer interview process look like?

#270

Post by C1sc0cat »

mcv wrote: post #258
C1sc0cat wrote: post #249

Earlier quoted context omitted.

But if experienced candidates go "meh" life's to short you might have missed a better candidate. And Martin any professional should adapt to the systems in place - and I wouldn't use terms like "random luser" might have some blowback.

If life's too short to continue with the final stages of an interview process, I don't know what to say. The whole idea, if you do it right, at least, is that you only give this test to developers that you already know you want. That means that for those developers, this is not one of dozens of tests they need to do, it's the one test; or one of a few, if they're that lucky. And if they're not interested in putting a…

Depends for many people there is not a shortage of jobs to apply for, so coding a path through a maze which is just regurgitation rote memorised algos is a filter for us.

I do agree about a daylong set of interviews with 4 or 5 people that's also a filter id use.

Post reply on HN