Live data from Hacker News

Hiring without whiteboards

github.com

271–280 of 372 posts

Re: Hiring without whiteboards

#271

Earlier quoted context omitted.

>My brain requires time to focus inward to formulate complex thoughts, and interrupting any time I pause narrating doesn't give me that time to think. So basically what you are saying is that you are some kind of snowflake that requires it's own room to concentrate and be productive and you can't even think while doodling on a whiteboard. In my books that counts against you, that doesn't mean you are straight out, bu…

Not even remotely. What I said is that I share a trait with about 25% of the population, more in software, where I can't do my best composing if I'm narrating at the same time. By "time", I mean 30-120 seconds without having to speak. In actual development that doesn't matter: pauses to compose an answer are fine in conversations and most work time is individual anyway (even in open offices). I do note, however, you…

>in what way is whiteboarding like real work deadlines?

hurdur, what is stress, I dunno. Why is everyone on this site suffering from autism?

Re: Hiring without whiteboards

#272
post #248

Earlier quoted context omitted.

>> 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 p…

Two things. . .

1 - I've been active in sports my whole life. I work 40 hours a week, play in several competitive hockey leagues and still have time to tinker and build stuff in my own time. I'm also studying to get my commercial drone license, and have a host of other hobbies that keep me busy outside of coding.

2 - The only way I feel like a developer can possibly stay in tune with how fast our industry is changing is to code outside of where they currently work.

A good example is at my current gig we're building apps with AEM (Adobe Experience Manager), Java and AngularJS (1.4). If I wanted to go work in a smaller startup, do you think my knowledge of 1.4 is going to be helpful when most of my friends who are working at similar places have been developing with Angular2 for almost 6 months now? If I'm not working on my own to keep up, my skills will be completely obsolete when I want to get a new gig.

That's just a fact of life. I don't have any friends who simply show up, work 9-5, spit out some code and then go home and not do anything. Likewise, they don't go home, crack open Visual Studio and code until they pass out on the keyboard. It's pretty easy to do stuff in your off time and still have a social life.

Re: Hiring without whiteboards

#273

Imagine this. You are interviewing for a job, you walk in a room with 2 people who hand you over a sheet with a few problems. They ask you to write the solutions on the whiteboard, while they wait for you to complete. Not a word is said, they are clicking at their laptops, and staring at the whiteboard, as waiting for the genie to pop out of a bottle. All the while your mind is frozen and stuck in a bad loop. This la…

I completely froze on a phone interview once. I opened up a co-coding application and was asked to write code to balance a binary tree as a warm-up exercise and I completely froze. Couldn't back out of my head, even with some prompting from the interviewers, and I ended up ending the phone call and writing a note of apology.

The painful part is, I used to teach CS-101 and CS-102. I assigned that exact problem to my students and have graded several hundred solutions to it.

Now I warm up on lots and lots of coding problems before I start an interview process, but I always worry in the back of my head that I'll freeze again.

Re: Hiring without whiteboards

#274

Earlier quoted context omitted.

>If they can't write some simple code unaided, then I don't want to work with them. I was a copy-paste programmer once too. Lovely. Someone put up with you, but now you won't do the same and offer to teach.

If you want to learn on the job and are happy to accept an intern's salary, that's great. Most organizations will be able to accomodate you. If you want $140k and can't code productively, most early startups won't want you. Larger organizations may be able to accomodate you. There are a shocking number of candidates who apply to senior positions who flat out cannot code. I have hired in the past without doing the whi…

>I have hired in the past without doing the whiteboard exercise and been burned by this; never again.

You should consider offering multiple technical tests and letting the candidate choose. Ideally the choices would range from whiteboard, take-home project, quiz site (hackerrank), or pair coding.

Re: Hiring without whiteboards

#275

Imagine this. You are interviewing for a job, you walk in a room with 2 people who hand you over a sheet with a few problems. They ask you to write the solutions on the whiteboard, while they wait for you to complete. Not a word is said, they are clicking at their laptops, and staring at the whiteboard, as waiting for the genie to pop out of a bottle. All the while your mind is frozen and stuck in a bad loop. This la…

When you get stuck, start talking. You should not be silent at the whiteboard trying to flash out a complete solution all at once. Talk. Even if interviewers are not saying anything or ask you any more questions. There are multiple advantages of talking while writing code at the whiteboard. Firstly, you show the interviewers the way you think and approach the problem. It is as important as actually solving the problem. Secondly, if you get stuck or start making unreasonable assumptions about the problem, the interviewers will have a chance to quickly correct you or give you a hint. Thirdly, it shows that you can communicate. Nobody wants to hire a person who can't communicate with other people.

Re: Hiring without whiteboards

#276
post #252

Earlier quoted context omitted.

> If I didn't know that you'd be asking for solutions I'm proud of, I might draw a blank at that moment. Granted it's an interview setting and these are the questions one needs to prepare for. The key word there is "prepare". These are standard interview questions that you just have to have a prepared, rehearsed answer for that you can rattle off without thinking. There are tons of these types of "behavioral" questio…

Yup, whiteboarding and reciting tried and true stories are inevitable routines when interviewing. However, you'd also be surprised at how many people don't know how to prepare for this. My main concern would be the possibility of turning a great candidate down just because they didn't happen to interview well.

> My main concern would be the possibility of turning a great candidate down just because they didn't happen to interview well.

Too bad (for candidates) that that concern doesn't appear to be shared by... well almost everyone in tech hiring these days. The general wisdom of the day seems to be "it's better to eliminate 100 false negatives than hire one false positive."

Re: Hiring without whiteboards

#277
post #254

Earlier quoted context omitted.

Sometimes it's worth taking action to diminish a perception, even if that perception isn't actually true. Has Google considered the impact of the perception that their interviews are hazing? Especially in the context of Google's public commitment to increase diversity among their engineers, it strikes me that revamping their interviewing process to eschew whiteboarding ought to at least be considered - it would be am…

I'm not certain that an interview process without whiteboarding - or at least some other form of coding test - would actually be able to detect the skills Google needs in their interviews. I see comments on HN time to the effect of "Why do I need to know how to traverse a tree or sort a trillion 32-bit integers? Why should I care about big-O notation? When will I ever use those skills on the job, when I could just Go…

Oh yes, they absolutely need a coding test!

Has Google innovated much in the interviews themselves in the last, say, 10 years? My perception is No. I get the impression that Google's old-fashioned process is a point of pride that they hang on to because it works (at least, the business is succeeding) and they are afraid of change. But it's a missed opportunity for a technical leader to advance the status quo in our industry.

For example, onsite, Google interviewers will still ask you to write code or pseudocode on the whiteboard. That's something they could re-examine (perhaps by giving an option of whiteboard or computer, and ensuring a level playing field between the options). They could get some good publicity from re-examining this, I think.

Re: Hiring without whiteboards

#278

Imagine this. You are interviewing for a job, you walk in a room with 2 people who hand you over a sheet with a few problems. They ask you to write the solutions on the whiteboard, while they wait for you to complete. Not a word is said, they are clicking at their laptops, and staring at the whiteboard, as waiting for the genie to pop out of a bottle. All the while your mind is frozen and stuck in a bad loop. This la…

Disclaimer: I work at Google but in no way do I represent my employer's views. These are all my personal opinions.

I interned successfully at FB, Microsoft and Google as a SWE in 2008-2010 and interviewed with a lot of other tech companies (not always but often successfully). Like you, I tend to freeze up in a whiteboard situation, and have most of my life, going back to college and prior (I studied in Romania where at the time you had to stand up and answer questions and use a whiteboard to answer them). I find that a few things help:

1. Practice practice practice. Simulate the interview with a few friends multiple times. It gets easier no matter how shy you are.

2. Smart interviewers and companies open with easy, friendly questions that put the interviewee at ease. It's a sign they understand this is stressful for everyone, no matter how confident, knowledgeable and smart they are.

While these interviews aren't perfect, with the right attitude they are helpful: it shows how the person thinks through a problem and communicates their ideas, and how they "work together" with the interviewer.

These are important skills that are important for all people regardless of their title.

I also believe a solid CS foundation is important even if coding is mostly putting things together. A systematic, mathematical understanding of complexity of Algorithms and Data Structures shows in one's everyday decisions.

There are only a few valid alternatives in my mind: 1. Take-home project work More realistic assessment of how effective a person is. Really good simulation of that, but no signal about their collaboration style, interpersonal dynamics etc. 2. On-site trial for a week or two This is probably the best way to assess someone's ability - internships and residencies are as close to real life as one can get. It's hard for people who already have a job, and expensive for a company to do. Simpler proxies/filters are needed.

Am I missing any other ways to assess candidates?

Re: Hiring without whiteboards

#279
post #166

Earlier quoted context omitted.

> But in general, I think the idea of the whiteboard interview is a chance to see someone "think out loud", to see them reason through a problem. So thinking out loud while coding is a job requirement now? I have been an engineer for over 14 years, and a software engineer for 10, and I can count on one hand the number of times I have done that outside of an interview. I collaborate all the time , but almost never syn…

Reasoning about problems is a very essential job requirement. And doing that out loud is the one of the few ways people can see how/if you do that.

>>Reasoning about problems is a very essential job requirement.

Sure.

>>And doing that out loud is the one of the few ways people can see how/if you do that.

Strongly disagree. I would posit that written explanations are a much better indicator of someone's ability to reason about problems, because:

a) They can provide hyperlinks, images and other supporting materials to aid their explanation

b) You also get to see if they are a competent writer, which is also a very important skill for an engineer

Re: Hiring without whiteboards

#280

Imagine this. You are interviewing for a job, you walk in a room with 2 people who hand you over a sheet with a few problems. They ask you to write the solutions on the whiteboard, while they wait for you to complete. Not a word is said, they are clicking at their laptops, and staring at the whiteboard, as waiting for the genie to pop out of a bottle. All the while your mind is frozen and stuck in a bad loop. This la…

Sorry you had bad experience. But I'd like to note here that many technical interviews that involve white board problem solving are nothing like this. I've attended interviews from a bunch of companies that do white board interviews. In almost all of them, the whole interview process went much smoother than this. Most importantly, nothing like "Not a word is said, they are clicking at their laptops, and staring at the whiteboard, as waiting for the genie to pop out of a bottle". If that happens, they are just bad interviewers.

White board interviews are supposed to be interactive. When I solve a problem, I always verbally say whatever is going on in my mind and share it with them. This does two things : 1. Helps me focus on the next steps instead of letting my mind race through different solutions, context switch often and lose track of my own thoghts. 2. Gives feedback to the interviewer so he knows I am on the right track and if not, give me clues (with or without him wanting to) that I can pick up on and proceed further.

In the end, my white board interviews always went like a conversation, a deep discussion about a problem that involves coming up with a solution and attacking it to see its pros and cons. I have come to appreciate the process itself because it tests several things like communicating to the team, problem solving, being open to other ideas etc.

Edit : I'd also like to note here that I didn't get these skills in my first interview. My first several interviews went horribly wrong like you mentioned. It is a skill that you need to invest time in. And you have to believe that the time you invest in this will pay off eventually. It did for me in several ways.

Post reply on HN