Hacker News new | ask | show | jobs
by deeg 2439 days ago
I do not want to work for a company that does NOT test my technical skills; if they don't verify my skills that means they don't verify others and I'd prefer to work skilled engineers (with exceptions for entry-level or junior engineers).

Most people seem to agree that white-boarding is a poor way to judge technical skills. Coding challenges seem a good compromise, assuming they don't require more than a few hours of time.

5 comments

I find as both an interviewer and an interviewee that I prefer whiteboarding.

But, it depends who you need to hire. If you need someone to just do the job. A coding challenge is fine. If you want someone who's above the rest in their CS knowledge, and problem solving skills, than a whiteboard interview is best.

Just my opinion. I have no data for this.

A whiteboard interview is pretty much a coding challenge where I can observe the candidate's methodology and their general approach to tackling problems. That's super valuable information.

From being a candidate myself, I've found that having someone watch me and being in a room with the stress and all motivates me to show my best. Whereas coding challenges I really lack the motivation and I end up rushing them, doing them last minute, and really not showing my best.

Ultimately, I think they both aren't ideal, but we don't have anything better short of an internship (and even those don't always pan out, since interns are treated differently and provided more hand holding).

In the end, it's just hard to reduce work that in practice spans multiple weeks per project, and involve all kinds of side process, to something you can test for in under a day.

> From being a candidate myself, I've found that having someone watch me and being in a room with the stress and all motivates me to show my best. Whereas coding challenges I really lack the motivation and I end up rushing them, doing them last minute, and really not showing my best.

OTOH, whiteboards or live-coding under interview conditions is a great way to watch me do worse work than I did when I was less than a year out from writing my first hello world. And yeah, I'm cool & collected under normal shit's-broken pressure, or client's-pissed-off pressure, on the actual job, which is totally different.

Same, I can't code while being watched, but I can do a take home assessment. My favorites have been real world stuff like ... build x by creating your own MVC w/ x, y, and z as a base... like x router, y templating engine, etc...
Someone on here posted something about letting candidates pick an open issue on an open-source project and prep a PR for it, to go over. Easily my favorite version of a take-home assignment I've ever heard of—it's not throwaway junk or contrived bullshit, and I get to claim the PR if it gets accepted, whether or not you hire me, so while it's not paid it's also not a complete waste of my time if the job doesn't work out—but it's not repeatable the same way for every candidate (which is kind of the point? I mean selecting the issue to tackle is part of the assessment, which, as long as there's a little guidance about the sort of thing that's considered good-enough so you're not entirely in the dark re: expectations, seems ideal) so a certain kind of hiring manager or interviewer will think it's necessarily crap.
That's genius. Almost sounds like something that could be it's own Startup/SaaS. A marketplace of code 'assignments' that OSS projects need done, employer can 'tag' assignments that they approve of, then you submit your work to the employer/oss project simultaneously so both can do a code review of it, if you lose the job but it gets accepted by the OSS then at least there's that. -- The employer would be the only part paying $$ for the platform, but it could be tax deductible as a 'donation' to OSS perhaps.
> I do not want to work for a company that does NOT test my technical skills; if they don't verify my skills that means they don't verify others and I'd prefer to work skilled engineers (with exceptions for entry-level or junior engineers).

This statement is assuming that short coding challenges measure something relevant to job performance. If everyone agreed that is true, this debate would not exist. We'd all agree it is filtering for the correct skills, we'd all hire the right people.

But the fact that it is such a perpetual debate is because a substantial percentage of developers disagree. I have certainly never seen any coding challenge (whether whiteboard or not) that has any relevance to the job. So as an interviewer I don't subject people to it.

I agree.

I kind of wish https://www.kalzumeus.com/2015/03/09/announcing-starfighter/ had taken off, as instead of doing a coding challenge for every company, you can do one really well designed challenge, and use that challenge with multiple companies.

Note: I'm an employee of gravitational.

I had a similar process recently. Went from recruiter through to offer with only a couple design problems and generally talking about projects I'd worked on, no code whatsoever. If anything, it made me want to work for the company less. I didn't feel like they had a great idea if I was actually good at my job, since almost everything I'd shown in interviews was things I could have easily made up to make myself look good.

That's especially worrying to me because it was a company that was still building out the team I'd be working for, so it would be hard for me to be really confident in the skills of my coworkers. Maybe the interviewers were just really good judges of character and skill (I think I probably was a good fit for the position), but it was hard to look past the fact that I didn't think I'd proven that I fit the role to them.

Not doing any technical/coding problems makes me worry that the company doesn't see technical skill as important at all. Maybe they could preface the process with an explanation of why they don't, and that could be persuasive, but outside that, even a basic FizzBuzz makes me feel like their hiring philosophy is considering those skills.

> Maybe the interviewers were just really good judges of character and skill (I think I probably was a good fit for the position), but it was hard to look past the fact that I didn't think I'd proven that I fit the role to them.

It's also possible that they are simply willing to fire people who are incompetent and prove to have lied about their accomplishments. If that's the case, it shouldn't be necessary for you to "prove" your skill, which is much, much harder to evaluate than most interviewers think.

I do get what you're saying, but what I'm really interested in is what are their skills? Any moron can tell me I'm good whether I am or not.
But the chance of getting it right goes down if they don't have direct evidence of their conclusion.