Hacker News Reader

Comment by malvosenior | Hacker News Reader

> There was no white-boarding, no solving difficult algorithms on the spot and no trick questions.

> I got through to the second stage on one job I applied for which was a take home coding exercise. The other interview I was offered the job on the spot.

This is how you interview. She obviously is very self-driven and a good communicator. If she were hurled some leetcode, there's a good chance she would have failed (as do so many devs with years more experience than her) and yet even reading this post made me think she's a great hire.

Managers: fight to change your hiring process. Throw out coding tests, leetcode and white board shenanigans. Invest in your own skills so you can quickly and accurately identify talented people. Take chances on unusual backgrounds. Not only will you save a bunch of everyone's time, you'll have a more organic culture and pick up diamonds that places like Google will pass over every time.

View on HN

My favorite interviews are when they give me a take home project that takes 2-3 hours and then during the technical interview you go over the solution and talk about ways to improve it. It gives applicants a chance to actually prepare for the interview in a meaningful way and I personally am much less nervous for this type of interview.

This is our approach. Choose one of five assignments, we ask for 100 lines of code, take it home, take as much time as you need. When you come back, we do a code walk through with the team.

We've hired only great people with this approach, and they've told me after the fact that they really appreciated that it tested them in a natural manner, rather than a type of competition.

I'm starting to feel like we're self-organizing a bit into types of companies based on our interviewing styles.

There are developers who excel at whiteboarding. There are those who excel at presenting their own projects from their github experience. There are yet others that excel in small code samples on company-driven problems, and some that excel in larger code samples.

The truth is that no one interviewing style works best for finding all developers that are a match for the company. Either we need to accommodate multiple interviewing practices, or we need to accept that we are going to gather in the companies that match our interviewing styles the best.

I wonder sometimes if there isn't room for a company that hires everyone who can fizzbuzz and is a good fit for the company as determined by behavioral interviews, and then accept a large attrition within the first 3 months.

I think the honest truth is that no matter what we do, interviewing is a hard problem.

> we ask for 100 lines of code

Why?

We don't want them to spend too much time. I tell them we don't expect them to spend more than 2 hours, and we're looking for 100 lines. I don't think it's reasonable to ask for much more of their time than that. Turns out they all wind up spending 8+ hours and most really get into the task.

I love a rough lines/size guide and will be stealing that idea :-)

The biggest risk with those take-home projects is that you'll lose out on the "2-3 hour project" because someone else spent 5-6 hours and had time not to just finish it, but to make it look very polished—unreasonably polished for 2-3 hours. So you either do it as directed and worry, or spend way more time on it (enough that I'd probably just pass unless it was one hell of a job)

Keep it small enough and you don't run into the thing where you're excluding the semi-happily employed, competent devs, because they don't really have to put up with your shit to find new employment, which is the case with those defined time (but not really) larger projects.

I think this is a great way to do it. I don't even give people take home assignments, but a small project coded on the applicant's own time, not in real-time with the interviewers watching is far superior to the alternative.

Live coding a problem you were just given, in front of strangers that are also evaluating you for a job is not a good way to evaluate candidates. Interviewing for a job is already a stressful situation, adding live coding to the mix takes it far into absurdly difficult territory. No real life job conditions match that type of situation, and if they do then there are other much bigger problems at play in that company.

I agree. For this particular role, there is little to no justification to use whiteboarding or Leetcode that would be relevant to this role. Being self taught + open-source contributions or projects is enough to get hired.

If this was for a more senior role with many candidates, I would raise the bar a bit to filter those that aren't serious or are unable to critically reason with technical/non-technical decisions. It's funny to see that most startups adopting whiteboarding practices can't justify their questions other than mimicking FAANG or stroking their egos over candidates by asking ridiculous algorithms questions they are unlikely to use, unless they can justified it otherwise.

Hiring is difficult because of managers that are still obsessed with finding the so-called "talent" when they're actually looking for that legendary senior 10x developer who knows them and the interview konami code, which wastes time and doesn't exist. The interview process in this article gets straight to the point which results in a justified hire of a very qualified candidate.

Well Done!

I think there can be just as many issues with that style too.

There are so many critiques possible, it's difficult to know what to focus on. Some people care about algorithm efficiency, and others don't. Some interviewers require test coverage and expect you to work under tdd. Or maybe you arrive and some guy frowns when you reveal you didn't prepare DB query plans for your 3 hour assignment.

I suppose what I mean is: it feels to me like just trading one kind of arbitrariness for another.

Coding in general is highly opinionated (who hasn't had a disagreement during code review).

I have had a particularly bad take-away experience and so I am shy of them now.

I've been involved in software for almost twenty years, and while I'd agree the a majority of whiteboard interviewing is done poorly, it is something that developed out of necessity to both filter bad candidates and have a more objective interivew process.

When I first got into the industry, it was much more rare to have coding tests vs. just general interviews, and that meant teams often hired the best talkers or the folks who boasted the most about their accomplishments, and those two skills had very little correlation to how well someone could code.

Even worse, 'team fit' was often prioritized above others, so be it on purpose or implicitly, good candidates from diverse backgrounds were much easier to overlook. When you have the majority of engineers solely focusing on 'can this person solve a problem', it is harder to argue against strong candidates just because they look older/younger/darker/lighter/more feminine/masculine etc.

Take home tests are incredibly biased against candidates without free time, and as I've pointed out in other places, can easily be abused by spamming candidates with them which is just not possible with whiteboard coding.

Coding tests are the best way to hire, if they are done right. They aren't perfect, but so much better than take home tests and 'discussion' based interviews.

As someone who also has 20 years of experience I strongly disagree. I've never experienced the mythical person who can talk their way through the depths and details of a project but can't code. I think that concept got cargo culted at some point, but it's not nearly as big of a risk as people make it out to be.

I think it'd be really fucking impressive if someone could discuss the ins and outs of systems they've used, likes and dislikes, taking conversational questions about it that they don't know about in advance, without setting off any alarms, while not actually knowing anything. That'd be wild.

I think a lot of the whiteboarding/leetcode stuff is just hazing, a desire for "standard" processes (every candidate has a different background, so a well-done conversational interview will differ a ton per-candidate), as a bit of a time-filler ("that's right [C-suite person who's asking questions] we have very rigorous hiring, look, it takes six hours, and see all these steps! Only getting the best of the best, I assure you."), and because if it's scripted you can have mid-level devs do it—poorly, for the most part, since conducting a good whiteboard/leetcode interview is possible, so far as that goes, but it's not easy and requires serious people skills, which is a big part of where places go wrong I think, and also tends to make it look so non-cookie-cutter that if you squint it's not really that much more "standardized" than the conversational version.

I think this is exactly right.

Sure, it's unlikely someone will be totally clueless who can talk the ins and outs of a project. Let me put it another way. If we put all the engineers I've managed/lead throughout the years through your interview process, you would probably filter out the one or two who were bad, but you would not always select the strongest engineers. You'd select the strong engineers who were confident, gregarious, and articulate, and leave out the ones who are humble, shy, embarassed by their accents, not used to bragging about themselves or articulating the details of past projects.

Talking about those things is a learned skill just like writing on a whitebaord. Hence why good companeis that do whiteboarding interviews also have traditional rounds. You want to give candidates multiple avenues to shine.

Not at all! My job as a skilled manager is to look beyond people who are outgoing and help people who are shy get comfortable during the interview. I've become very good at this and have trained other managers to do the same.

A casual conversation where someone is purposefully trying to put you at ease is going to be more effective at seeing someone's true skill over a whiteboard every time.

There are also a bunch of very senior people that won't play interview games at all. Especially when they're an internal referral. If I refer someone to get hired, I make absolute sure that they are not put through a technical hazing ringer. I've seen senior people who were heavily recruited walk the instant they're put into "the process" under the very sound logic of: "You wanted me to work here, so why are you making this difficult?"

Outside of SV these kind of saner interviews are the norm. It's totally possible to get a job if you straight up refuse to do whiteboarding.

Outside SV they'll send you absurd hackerrank problems after a 5 min phone call with a recruiter on contingency.

Which is arguably worse than whiteboarding.

This is also a standard in Boston and now Austin TX.

Lots of places in DC do this as well. I think it's mostly a startup thing. I commonly refer to one of the greatest C++ programmers of all time (Scott Meyers) as an authority on this stupid hazing ritual.

"I hate anything that asks me to design on the spot. That's asking to demonstrate a skill rarely required on the job in a high-stress environment, where it is difficult for a candidate to accurately prove their abilities. I think it's fundamentally an unfair thing to request of a candidate."

https://en.wikipedia.org/wiki/Scott_Meyers

Places with ex-FAANGers in decision-making positions seem to favor it. Nevermind their business is a boring-ass CRUD app and their anticipated usage patterns will only require solving "hard" problems to scale if they totally fuck it up.

[EDIT] and on the topic of your quote, in actual work screwing up while working through problems in a meeting or while collaborating is (or had better be) normal, and everyone's working together to find the right solutions. If you miss something you missed it, that's fine, even if it was something dumb, everyone does that all the time, NBD, unless you're doing it just constantly no-one will think a thing of it. Expectations, explicit and implicit, in an interview make it way less friendly and safe feeling than even a very important or relatively high-stress task in actual work life. It's not even in the same category of activity as solving problems at work.

Sorry, but this is simply not the reality in software dev interviewing. This is a great story and all, but this kind of media is setting up people to fail.

Making candidates white board is basically an ego driven hazing process, "we had to do this stupid exercise, so you have to as well! Ha ha!"

It also gives people a bad taste in their mouth, don't ever forget the candidate is interviewing the company as well.

The best response is to immediately walk up and leave when asked to white board something, stating something to the effect of "sorry but if this is your company culture, I'm not a good fit". I know several people who have done this and were hired anyway.

Look at a candidates successes and body of work, if their competency isn't obvious from what they have demonstrably accomplished, they probably aren't the right candidate. No amount of white boarding (or the nonsensical "thought exercise" questions) is going to change that.

There is no public body of work if the person kept busy working under an NDA. You certainly couldn't see the code (not that you could know who did what as part of a team) and you might not even get to know what the project was.

I do this but clarify what the interview process is like as a first step to communicating with a company. As soon as they state this as their intention I tell them I'm not interested. I've been hired at places anyways. My personal opinion is that I have enough projects, years of experience getting a paycheck each week and GitHub/Stack Overflow contributions to verify I at least have a grasp of what it takes to be a web programmer. I refuse the white board exercises outright. I won't do large homework assignments either.

Reply on news.ycombinator.com