Live data from Hacker News

Hiring without whiteboards

github.com

231–240 of 372 posts

Re: Hiring without whiteboards

#231

Earlier quoted context omitted.

When an interview is not a discussion, but rather a test, it is a bad interview.

Now that I think about it, I wasn't asked a single programming question when I was interviewed for the job I have now. I was asked architectural, process improvement, soft skill questions. That's probably why I chose the job I have over other offers. It was more of a discussion and by the end of the interview, I was joking around with the hiring manager and said something to the effect of "I'm already assuming I'm go…

Most interviews I've been to have been the same. I was talking about the ones where you have to solve some tricky algorithm questions at a whiteboard while someone is staring at you. I have no problem doing that in front of my colleagues, but find it difficult to do at a job interview.

Re: Hiring without whiteboards

#232
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…

That isn't the metric. Read the tl;dr.

Re: Hiring without whiteboards

#233
post #213
post #96

Earlier quoted context omitted.

If it's automated, or direct from a recruiter - chances are the company hasn't even read my CV. Or looked at any of the previous work I've included. Of course it's disrespectful.

deleted

>"Why would a company look at your CV? At best, it's full of exaggeration. At worst, outright lies."

So by your reasoning CVs are not meaningful at all. Should we get rid of them? Why stop there though, should we not even discuss past projects we have worked on in interviews since those are also likely exaggerations and possibly outright lies?

Re: Hiring without whiteboards

#234

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…

Whiteboarding itself is a skill. What I learned the hard way: - There is no insert. If you need to go back and insert a line of code somewhere you must either erase all the code below it to make room (then rewrite said code), or you draw a line from the insertion point to somewhere else on the white board and write the code there. For the former you waste a lot of time. For the later the code quickly becomes hard to…

All your points are good--and they are part of the overall problem with whiteboard coding: A whiteboard is not even close to a realistic modern development environment.

How many times, for your job, have you had to code up a solution to a problem, even a trivial one:

1. Just given to you 5 seconds ago

2. With no access to documentation (paper, textbooks, offline or online resources)

3. With no access to mentors or colleagues

4. With an editor crippled as you described

5. Have to get it right within minutes?

6. And then have to defend your code against someone who's had plenty of time to think about the problem.

I can tell you, throughout my programming career, the answer is "never".

Re: Hiring without whiteboards

#235

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…

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 not really in charge, but they're technically in charge with time at the company and the title.

I'm not saying throw deep algo questions at them, but promotions don't mean coding chops.

Re: Hiring without whiteboards

#236
post #147

Earlier quoted context omitted.

> If they start talking about whether or not the arrays are sorted, how big they are, whether you could refactor the array building code to return the data as a object index instead ... then it's clear that the person knows how to code simple things, and all without needing to pick up a marker pen Having worked with people like this, I have to call BS. There are a lot of people with the distinct skill of being able t…

> Having worked with people like this, I have to call BS. There are a lot of people with the distinct skill of being able to effectively imitate the speech patterns of actual programmers. Asking questions, engaging in productive discussion, etc. But when faced with an empty editor, they simply cannot produce working code. Having never worked with anyone like that, I will have to call BS on this because it is simply t…

I've worked with people like this, and it's still hard to believe with evidence. I've changed my interview style from asking questions about programming to one that has candidates do a small design, then write one or two small programs implementing the design they just did. A surprising number of candidates are able to complete the design part well and then unable to make any real progress on the code. Most of them were phone screened before my interview; some had multi year careers in the industry. This feels different than people who are nervous or otherwise having a bad day, as they are exuding confidence while simultaneously being unable to write a while loop.

Re: Hiring without whiteboards

#237

Earlier quoted context omitted.

I am interested in this too. I recently failed netflix code review because I used java 7 instead of java 8 which apparently showed them I don't keep up with new technology (even tough the question asked me to pick any language on jvm.) Other reasons given to me were that i used maven instead of gradle. https://medium.com/@meowlicious99/my-software-engineer-inter...

> all my open source code is written in java 8 for him to look That completely defeats the purpose of a small, self-contained assignment like the one you were given. And your code isn't even in Java 7 (no diamonds), I think it was a legitimate remark.

You think it would be helpful to let the candidates know what they would be evaluated for in the coding assignment.

I would have dazzled them with java 8 if I knew I was going to be rejected a based on that :D

I was under the impression that this was the usual algorithm/data structure/complexity rigamarole, not show us latest language features.

Re: Hiring without whiteboards

#238
post #66

Earlier quoted context omitted.

But this is an endless cycle. At some point, the company has to apply some test to see if the candidate is appropriate, IE, can code to the required standard. That will require a time investment from the candidate. You could simply get rid of the take home test; that will shift the burden to the resume and cover letter, to the advantage of humanities graduates like me. You could mandate a full day on-site, which will…

I'm not really advocating for getting rid of take home tests entirely. There's a lot of value in seeing how someone approaches a known problem and being able to compare that to other solutions. What I am asking is that companies don't ask me to invest hours of time before they decide if they're even interested in talking to me. At the very least I want to have had a phone interview and the chance to assess whether I'…

>"What I am asking is that companies don't ask me to invest hours of time before they decide if they're even interested in talking to me."

I feel like this is the crux of it as well. I am not against projects or tests to show I am technically qualified. But this should be after talking to some potential team mates to see if there is even a fit, personally, work culture-wise, technical interest or any number of factors that you could glean by speaking to potential colleagues for 20 or 30 minutes.

Re: Hiring without whiteboards

#239
post #185

Earlier quoted context omitted.

Part of this is that a lot of interview practices (including whiteboarding) exclude people that suffer from social anxiety. Just because somebody freezes up when being watched and critiqued by an Evaluator, doesn't mean that they are 'copy-and-paste programmers'. There are probably a lot of extremely good engineers who find this style of interview difficult. People that call 'whiteboarding' a skill don't really get i…

"People that call 'whiteboarding' a skill don't really get it. If you have irrational fear over people's judgements and this manifests when you're being interviewed, you can't merely expose yourself to this fear often to lessen it. It is very difficult to change how your mind and body react to uncomfortable situations. " I disagree on a few levels. I can't back anything with data but I'll point to where you can find…

Except that interviews are different than any other form of workspace interaction, except, possibly, for presentations (but not really). When being interviewed, candidate is not [only] solving the task of getting things done and done well - they're struggling with the task of appealing to others.

Interacting - be it in a normal non-stressful environment, or in most stressful emergencies when everything's on fire - is almost entirely different experience. I guess, primary difference is that no one judges you (at least, not explicitly) but you're working with the team to reach some goal.

Maybe there are interviews where interviewers are there to actually help candidate to tell about their good and bad sides and even receive useful feedback and not just "thanks, we'll contact you [never]". Wish I'd be to one, because every one I was to (not much) felt like an exam with a taste of scrutiny.

Re: Hiring without whiteboards

#240
post #227

Earlier quoted context omitted.

...that's more interview technique, not actual coding skill. The skill and art of "coding" is in finding solutions to problems, not "writing code". When I interview people I'm looking for someone who can explore problems, ask questions, and find good solutions. If they don't feel like they have enough information I expect them to question things. If they're working on assumptions (like 'what does the array actually l…

The fundamental part of the job being reading your mind? For every interviewer who asks how to find if a number is in both arrays and is expecting a detailed discussion of he to do a nicer job by not actually having arrays, there's another interviewer who just wanted to see if the candidate can write two loops, leave the loops early when the value is found, and not run the second loop if the first one doesn't have th…

The fundamental part of the job being reading your mind?

The fundamental part of the job being that writing code without having a good understanding of the problem is a waste of time and often leads to throwing things away. If an interviewer was annoyed that I asked for more information about a problem before writing any code I'd take that as a sign I wouldn't really fit in at the company.

I was a cofounder at a startup that was trying to improve requirements management for a couple of years. This might go some way to explain my attitude about this. I really hate writing code to solve problems without having enough information first. It's so wasteful.

Post reply on HN