Live data from Hacker News

Hiring Without Whiteboards

github.com

211–220 of 471 posts

Re: Hiring Without Whiteboards

#211

Earlier quoted context omitted.

I hate take-home projects more than I hate whiteboard interviews. I think the best approach would be giving the candidate a broken app and have they debug it live or in a take-home debug-and-fix or debug-and-improve exercise. Could also have some refactor assignment. Has any company tried something like this before?

Apple did this in one of the sessions last time I interviewed there. They handed me a project in Xcode that had a number of bugs with varying degrees of difficulty — some caused crashes, others were UI glitches, etc. The assignment was to identify the problems and fix them. If you have more than a couple years’ experience the issues were pretty straightforward. I really enjoyed this session, but I can see how it coul…

This sounds really cool.

Re: Hiring Without Whiteboards

#212
post #203

We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we've implemented. We ask fo…

How do you avoid awarding candidates who violate your request of no more than two hours and spend considerable time coming up with something amazing? They may still produce 100 lines of code — but those 100 lines may end up being unusually elegant, beautiful code that stumps 40 year veterans. How do you avoid punishing someone who took your requested time constraint seriously (or otherwise didn’t have enough free tim…

I'm of the opinion that this is fair enough as long as the pay isn't crazy high. The truth is, no interview is ever truly fair, and all interviews can be gamed. "Grinding leetcode" is much the same problem you are describing wrt spending 40 hours on a 2 hour project. People game non-technical interviews too. And resumes.

It sucks, but you only need to be better perceived than the next best competitor. Most folks don't have 40 hours to spend on a 2 hour max coding challenge. Hopefully the ones that do are already employed and not currently competing with you, or are so inexperienced that 40 hours produces horrific over-engineered abominations instead of clean efficient readable code.

Re: Hiring Without Whiteboards

#213
I am probably one of the very few who prefers whiteboard problems compared to knowledge based problems. In my career spanking over 12 years, I have worked on ASP.NET, Silverlight, Blackberry, Android, Node.js, HTML/js/css, Xamarin, .NET Core, Code generation, Java microservices , Native Windows and AWS services.

The result of working on so many things is that I am not an expert in any of those topics. While I do well in generic system design interviews, I lack depth in literally every single thing that I have worked on. So inspite of having more than a decade of experience, I don't satisfy the criteria for companies who ask for 'x' years of experience in 'y'. So whiteboard and algorithm problems work well for me, because there's not really much to learn and memorize in those topics.

Re: Hiring Without Whiteboards

#214
post #203

We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we've implemented. We ask fo…

How do you avoid awarding candidates who violate your request of no more than two hours and spend considerable time coming up with something amazing? They may still produce 100 lines of code — but those 100 lines may end up being unusually elegant, beautiful code that stumps 40 year veterans. How do you avoid punishing someone who took your requested time constraint seriously (or otherwise didn’t have enough free tim…

I reject entire the premise of this question. Anyone spending huge amounts of time is either going to produce way too much or they just took too long. There is nothing magical about programming where taking 8 hours to solve a 2 hour problem is going to stump 40 year veterans or be unusually beautiful. That's just unrealistic.

Re: Hiring Without Whiteboards

#215
I live in Sweden and we seem to have a very different interview culture. I've never heard of whiteboards or trivia questions, here.

I've only gone to four interviews (across eight years), and been lucky to get an offer each time (three of which I've accepted). They have all been primarily discussions about personal experience, hobby projects, personal interests, would-be responsibilities, benefits, and company culture.

At one place (Ghost Games, an EA studio and the only company which wasn't purely Swedish) I had to complete a code assignment (create a clone of a classic arcade game in C++) ahead of the interview.

Re: Hiring Without Whiteboards

#216
I think the problem is similar to the problems in systems engineering, where techniques and processes can de-rail real engineering progress. This has been observed back in 1969 by Robert Frosch, who served as NASA administrator:

"I can best describe the spirit of what I have in mind by thinking of a music student who writes a concerto by consulting a checklist of the characteristics of the concerto form, being careful to see that all of the canons of the form are observed, but having no flair for the subject, as opposed to someone who just knows roughly what a concerto is like, but has a real feeling for music. The results become obvious upon hearing them. The prescription of technique cannot be a substitute for talent and capability, but that is precisely how we have tried to use technique."

- http://origins.sese.asu.edu/ses405/Additional%20Reading/Fros...

Current technical interview processes with its whiteboards and technical questions will undoubtedly lead to hiring the first type of music student.

Re: Hiring Without Whiteboards

#217
I don't fully agree with the part of the title that reads

Companies that don't have a broken hiring process

Only because they don't currently do whiteboards. I feel like interviews in general is a tough problem

Re: Hiring Without Whiteboards

#218

We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we've implemented. We ask fo…

How do you feel about paying candidates for the time they spend on the assignment?

I created a similar task at my company as the parent commenter, building a small frontend to an existing API that can be completed in a couple of hours. There's no time limit for turning it in (we suggest two weeks but don't enforce it) and we specifically tell people that a good, concise solution to the problem at hand is perfectly fine, and even might be better than a sloppier solution that tries to add bells and whistles.

When I set it up the goal was to avoid a lot of the issues I've personally had or heard about with coding challenges: they take way too long, they're too abstract, or you feel like the company might just be using you to get a couple of days of free work on their actual codebase. For this reason I feel fine about not paying people, as it's just a small part of the application process and not free work for us.

I think it's worked pretty well so far. It happens after the initial phone screen and before the first technical interview. We send people the challenge, they return it whenever they want, and if we like it we set up a technical interview. Since the challenge uses our tech stack and is similar to the work we actually do, a large part of the first technical interview is discussing their solution. Why they chose certain patterns, why they added a certain library, how they'd consider testing it, why a certain function might be slow with 10k entities, and so on.

Re: Hiring Without Whiteboards

#219

We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we've implemented. We ask fo…

How do you feel about paying candidates for the time they spend on the assignment?

I once applied at a company that started with a programming test before any human communication. I think I did a pretty good job on the test. After that I was rejected when I assume they saw my resume. They gave me $50 store credit on their website (custom sticker printing). I assume it cost them a lot less than $50 but it was still pretty cool.

Re: Hiring Without Whiteboards

#220

Earlier quoted context omitted.

I hate take-home projects more than I hate whiteboard interviews. I think the best approach would be giving the candidate a broken app and have they debug it live or in a take-home debug-and-fix or debug-and-improve exercise. Could also have some refactor assignment. Has any company tried something like this before?

I don't understand how take home interviews are being held up as a better solution. They have two major flaws: They lower the cost for the company to zero. So they can widen their pool, and take a chance on more candidates, with no extra cost incurred for them. If you take this to the extreme – every company asking every candidate to complete a take home – then the result is far worse for candidates. There is no feed…

Totally agree. I've almost never completed a take home project (even though I liked the concept) because there were always other companies I liked that didn't demand as much of my time whose interview process moved faster and who gave me offers before I finished the take home interview process.
Post reply on HN