Live data from Hacker News

Hiring without whiteboards

github.com

241–250 of 372 posts

Re: Hiring without whiteboards

#241
post #202

Let's agree Hackerrank sucks. Develop a shity solution in a very limited time, using ES5 and no libraries for JS, waste time parsing your input where the first element means nothing and the other must have the type converted several times.... If you really want to test a candidate, give them unlimited time, a "real problem" and something that they don't know.

Why something that they don't know? (Actually curious)

Most of your work is to learn stuff, to figure out solutions for new problems. However some people keep themselves in their safe-zone, avoiding new kinds of tech or solution. I belief that a good developer will like the feeling of frustration when learning something that they don't know, that a bad piece of code will make then uncomfortable.

The skill that I look for in another developers is the ability to learn stuff that they aren't trained. This way I know that they will be able to solve new problems, to find better solution for old problems. By testing then in something that they don't know, I will see if they are open to learn new stuff and able to apply new concepts, and ask how they felt about it later.

Re: Hiring without whiteboards

#242
Meh, if you can't even handle a tiny whiteboard situation how are you going to handle any deadline pressure? It's not about knowing the right answer off the top of your head, it's more about how you work and approach the problem.

Sure some bad companies expect you to be able to write something very specific on the spot, but thous are pretty rare imo.

Re: Hiring without whiteboards

#243
post #208

Using the presence of whiteboard questions as a metric for interview quality seems rather pointless to me. Whiteboards questions can be very good or can be very bad or anywhere in between. Just like any interview question in general. I for one prefer whiteboard questions to generic open ended personal questions. Good whiteboard questions can quickly assess whether someone knows the basics of programming or not. Open…

Early in my programming career, I got a whiteboard question where, after being asked my hobbies, I was asked to diagram an electric guitar on the whiteboard. I don't know that it was a particularly good question. But all this sabre-rattling against the whiteboard in general just seems like a silly distillation of a legitimate critique down to its stupidest form. Even when it comes to CS algorithms questions. Yeah, as…

That reminds me of an interview I had for a sales position. The guy man asked me how to tie a shoe. I actually really thought it was an interesting interview question, despite not being strictly sales-related, because teaching is a really big part of sales.

I like that guitar question for a similar reason. Someone once told me that you can't program something you don't understand. Being able to break down a complex topic in to atomic parts is the difference between someone who can program, and someone who can develop applications that solve problems.

I'm an analyst rather than a developer, but most of my value comes from being able to communicate information to other people. I know there are people who are better than me at programming, or statistics, or modelling, etc. However, I know that I can be incredibly successful in any given role if I take the effort to learn as much as possible about whatever I'm analyzing, and if I focus on communicating the information as clearly as possible.

To that point, I'm really proud of the fact that the man who interviewed called me afterwards to say that I had given the best instructions for tying a shoe he had heard in 30 years of asking that question in interviews. That being said, I can see how someone who is a nervous interviewee would resent questions that seem designed to trip them up.

Re: Hiring without whiteboards

#244

Earlier quoted context omitted.

> The whiteboards seems far more respectful of people's time at least. Some companies will happily bring you on site for a full round even though they have no idea whether there is an open position for you (infamous example, you can pass Google's hiring committee and then be told there's no headcount). And you've just wasted one day off. On the other hand, take-home projects can be used in a way that saves everyone a…

>"Some companies will happily bring you on site for a full round even though they have no idea whether there is an open position for you (infamous example, you can pass Google's hiring committee and then be told there's no headcount)." In practice though this is kind of rare especially for the larger SV companies. I'm not saying it's never happened but that Google incident sounds like an anomaly. How do take home pro…

Not everyone lives in the SV. If you interview at a satellite branch of a company that has a big and generic interviewing pipeline, it can definitely happen.

I can do a 4 hour[1] assignment on my own time, assuming I'm not given an unreasonable deadline. For a full round of interviews on site, I need to take a day off. That's a huge difference to me.

[1] I've rarely been given any assignment taking more than 2-3 hours, I would flat out refuse anything that can take more than 4.

Edit: oh and I can give you a very long list of companies that thought I was "qualified" after 1/2/3 phone screens, wasted a lot of my time afterwards, and ended up deciding I wasn't :)

Re: Hiring without whiteboards

#245

Earlier quoted context omitted.

If somebody has been promoted multiple times in programming roles, and especially if they have a visible open-source corpus (not necessarily GitHub BTW), then you know they can code. Making them do it in a highly artificial environment is pointless at best . Other words like "insulting" and "demeaning" also come to mind. Asking people to reason about complexity is great, but that's not the way such interviews usually…

> If somebody has been promoted multiple times in programming roles...then you know they can code That's not necessarily true. There are people in "tenure" roles as I like to call them. They're not ostensibly bad, but they're far from good. They get promoted to senior developer and have pay raises each year. They're not bad enough to be let go, but after 5 years, they're still around and earn a senior title. They're…

You do have to look at the role. If their role is to code, and they've been promoted recently, I stand by my claim. If they've moved into more of an "architecture" role or the promotion was more than a couple of years ago, then yeah, they might have lost it.

Re: Hiring without whiteboards

#246
post #211
post #131

Earlier quoted context omitted.

> > That said, I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of. > It could be that this technique favors people good at telling stories. Or people who think they're impressive. I know I would've been able to point out many problems and solutions I found interesting and were impressed with when I was 15. Today, not so…

I'm not a "look at me!" kind of person, but here's what has really helped me with these kinds of interviews. Keep a daily journal of what you work on. Nothing fancy, just stop by once a day religiously and add a few notes on what you did, what meetings you attended, who you spoke with, etc... Save your evaluations and especially any award packages you or your team might get submitted for. At least where I work both a…

My grandfather used to do this. He had notebooks filled with what he did every day of his career. It's really cool to be able to go back and look through his notebooks and see what he was doing in April of 1971.

My notetaking is not as rigorous as my Grandfathers, but I do something similar. Every month I make a new manilla folder with the month and year on the tab. Each week I write down every project I'm working on and every meeting I have. If someone brings me a new project I put it on the sheet. Every note I take a meetings and during projects goes in that folder.

At the end of each week I go through the notes from that week and write down anything interesting on that week's note sheet. At the end of the month I go through all the notes and write what I accomplished on the front of each manila folder.

It makes it really easy to keep track of everything you've done, without consciously keeping a journal in the moment. It's also a really easy organizational system. When someone asks, "What did we do for [x] in the past", all I need to do is flip through my folders looking at the front for anything that rings a bell, rather than trying to keep up with a tagged organizational system.

This probably doesn't work if you don't have a file cabinet though.

Re: Hiring without whiteboards

#247

It's funny, whiteboard interviews really would be a better discriminator for founders than employees. They test confidence rather than competence (or technically, competence + confidence). The former is incredibly important for founders, but the latter is probably what you care about more for employees. And yet founders almost never do a whiteboard interview, yet it's standard for technical employees...

Well, for a random employee of a random company there is no motivation to not haze people on the whiteboard, it's mostly a power play for them and oversupply of candidates permits it. They really don't care how good of an engineer they hire and how much value he can bring to the team or to the company.

I don't think that's true, actually. I've been both interviewer and interviewee, almost all my friends do interviews, and in every case I've seen, the interviewer is earnestly trying to make her best determination of whether you can succeed at the company. Most interviewers - both ones I know as friends and ones that have interviewed me - get very, very happy when they find a candidate that they know will meet the hiring bar, because it's such a rare occurrence.

I think that the perception that it's just a hazing process comes from a failure to look at it from the company's perspective. Most people know that they're good programmers (whether it's true or not...), and so they're like "This is bullshit...why do I need to prove my worth at the whiteboard when I know that I'm a good programmer." But the cost of a bad hire is really, really high (both for the company and for the employee), and the applicant pool is skewed through adverse selection, and a company knows nothing about you when you come in to the interview. Many people with stellar resumes can't actually code; some that can code don't actually want to work with you and would be bad cultural fits; and some outright lie on their resume. They're trying to figure out, in a 50-minute hour, whether you'll be productive on the particular problems that that employer faces.

Re: Hiring without whiteboards

#248

What's with all the whiteboard backlash? I ask simple questions and expect people to be able to write code unaided to express their idea. Not "implement a linked list" or "write quicksort" but basic "You have two arrays - find if a number exists in both arrays" sort of thing, primarily to reason about runtime complexity, and to make sure they can actually write code. If you tell a candidate to prepare, they should be…

>> What's with all the whiteboard backlash? Here's the deal. As a developer, I have about 30 repos out on GitHub with plenty of examples I've done in the last three years. If you want to interview me, then go look at my code first. I have a pretty specific style so all the code is consistent. Go look at my code, dissect it, ask me questions about it, ask me why did this instead of that, why I prefer some library over…

Your last paragraph here implies that a developers work is either A) able to be shared and not owned by their employer, or B) they spend their free time coding after doing it at work all day, instead of having other hobbies. If thats the bar an employer wants to set, thats perfectly reasonable. They shouldn't ever complain about not being able to find employees however, if they are going to artificially limit their prospective employee pool to people who have no interests outside of programming

Re: Hiring without whiteboards

#249

Earlier quoted context omitted.

My view is that you can't have competence at a certain level without confidence - unless you're just an easily outsourced code slinger. I'm often at a whiteboard explaining architecture, ideas, etc. How do you do that without confidence and some semblance of emotional intelligence.

There is really no comparison. Explaining architecture, ideas etc to your colleagues has pretty much no resemblance to a whiteboard interview, where you have several people staring at you and judging you. One is a discussion the other is a test, they compare like having a beer with a colleague is like holding a speech in front of a bunch of stranger.

One thing I've always been curious about is why folks are so afraid of being judged. Most people are judging you all the time, yet recognizing this fact causes a lot of people intense anxiety. I'd rather look at it as a selection filter: if someone doesn't like you or doesn't want to work with you, that's a strong signal that you'd be better off not spending any more energy on them, and instead focusing on the folks who do like you & want to work with you.

Re: Hiring without whiteboards

#250
post #220

Earlier quoted context omitted.

Calculating the volume of a cylinder is trivial.

What does that have to do with solving problems? If you can't do it off the top of your head, a quick search will give you the formula and then you plug it in. Questions like this make me not accept a job offer for a place.

In general I don't like questions like this either, but this particular one seems designed to test your wits if not your memory: if you don't happen to remember the formula, you can quickly derive it. I bet if you said out loud "It's the area of the end circle times the height of the cylinder", you wouldn't have to go any farther.
Post reply on HN