I'm responsible for hiring developers at our company based in Berlin, Germany, and found it best to have a guided interview about the candidate's work experience and interesting problems that she/he solved. I never understood the whiteboard hazing/CS trivia that are so widely discussed on HN since it seems extremely disconnected from the actual work that's being done.<p>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.<p>We worked with an HR consultant to develop a interview guide in the form of certain questions that we make sure to hit during the interview in order to be able to compare between candidates and make an informed decision.<p>However, we're small and not in the US. Anyone have experience with other companies in Germany/Europe? How does the typical interview work over here?
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.<p>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.<p>This lasts an hour, you are barely able to complete parts of the problems and are frozen. Of course this affects your usually creative and sharp mind.<p>The torture lasts an hour, time's up! You shake their hands, as a kiss of death, and head out. As you are walking back, all the answers to all the problems they wanted you to whiteboard, come rushing like a torrent in your mind. Too bad, another 'botched' technical interview.<p>This is my experience as a battle tested developer who is shipped many products and has been programming for the love of computers since the age of 12 (professionally for more than 15 years). I am not going to be working at Google any time soon (not that a Google job really matters to me).
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.<p>If you tell a candidate to prepare, they should be able to come in and do this. 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.
I would like to see a compilation of companies that aren't requiring a "coding project" as part of their interview process. I much prefer to write on a whiteboard as part of an onsite interview than to do a "coding project" for every single company that "might" be interested in me.<p>My experience lately has been an immediate request to complete a coding project right after speaking to a recruiter but before speaking to anyone technical. And perhaps the height of absurdity I have even had automated emails saying "thank you for you interest we invite you to complete this coding challenge/project."<p>Are you really expected to do one of these now for every single company you send your CV?<p>The whiteboards seems far more respectful of people's time at least.
I think coderpad.io is the modern day equivalent of a whiteboard.<p>It's nice that you get REPL and a keyboard, but the unnecessary pressure of being watched, critiqued, and timed are all there.<p>My mind just goes completely blank whenever I am put in this scenario.<p>Are we programming or defusing a bomb?
The problem with whiteboards, is they're not reflective of real life. When was the last time you can honestly say you used a whiteboard to solve a programming problem instead of Googling and ending at a StackOverflow question with a great answer? I've never used a whiteboard for programming. I've used plenty of whiteboards for things one level back; planning, prioritising and visualising task related things.<p>The reality of programming is, these days everyone Google's their problems. Sometimes you end up at StackOverflow or sometimes you find yourself on a random blog or official documentation. Occasionally you ask a coworker for help, but the ego a lot of developers have to be smart means most feel intimidated to do so. And sometimes you just bang your head against your desk until things start working.<p>Whiteboard and highly technical interviews that expect you to know high-level computer science concepts are tilted in the favour of graduates who are freshly minted from whatever respective educational institution they graduated from.
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...
It really is terrible. Companies need to accept this.
You're sitting behind me. Or beside me. I can smell your breath. Or you're on a webcam. It's voyeuristic. You've already solved this problem. Perhaps you even designed it. Your talking is breaking my concentration. This is not how I work. It's probably not how you work either, and if it is, I think we're done here.<p>Now, if a company insists on an adversarial process, there are better ways to do it. The nature of the problem is given in advance. Both the subject and the evaluator go in blind, and they both do it.
The main purpose of whiteboard is to decrease the liquidity of job search for engineers, thus depressing wages. After a few years of doing design docs and copying protobuf fields, the median engineer at a top company would need a month of prep to be able to pass whiteboard interviews again. Much more effective than secret no-poaching agreements.
OMG it's happening!<p>I was always puzzled by how unrelated metric used for hiring is to actual work at many companies.
I don't mind algorithmic brainteasers - on the contrary I would absolutely love to solve such problems at work yet those seem to be scarce.
I also don't mind other types of developer work - be it more research or architectural oriented or "just" coding.<p>But I am not happy learning something different for interviews every few years and then forgetting it over the course of next period of day to day work. Feels like a waste of time and is confusing in regards to what one would actually do in certain job.
Why the universal hate for whiteboard interviews? I studied computer science at a German university and it was expected that in the exercise groups you are able to solve the exercises that you prepared on a whiteboard from the first semester on. If you did not solve it sompletely you still had to whiteboard-code the parts of the solution that you were able to and improvise the rest.<p>For more complicated algorithms I still love to draw lots of pictures before implementing them.<p>I can understand that people complain that they have to solve tasks (on a whiteboard) that won't have to do much with what they will do at the job. But this has nothing to do with whiteboard interviews, but with badly chosen tasks (say: data structure brainteasers) for the job interview.
I have a question. When you hire complete freshers out of school, how do you interview them without asking for CS stuff? In my experience, fresh undergrads usually do not have any real world experience.<p>I have experimented with short take home projects. This drastically reduces the available pool, since great freshers can get job in other places with whiteboards interview. Also, there is a sense that interview process is used to get people to do free work.<p>Also, non whiteboard interview processes are extremely time consuming. Non-whiteboards interviews will be better. But as a matter of practical experience, I have found it to be the only viable option for hiring fresh undergrads.
Main main gripe with whiteboards is that it's hard to add extra lines.<p>If you're writing a loop for instance, you might code up the per-item logic first, and then you remember you need a loop variable. Which there's now no space for, because in a normal coding environment you can just insert the line where it's needed.<p>It makes me feel like I need to have solved the whole problem before writing, and that's just not how coding happens.
Am I the only one who thinks the pressure a whiteboard adds is actually something valuable? In my last job there were a lot of situations where you had to solve a real problem under extreme pressure. People who couldn't handle it simply weren't cut for the job.<p>I don't think all interviews should use it but for us it was good for filtering out candidates who would not perform in those situations.
Just ran through 2 complete interview cycles without touching a whiteboard once.<p>Got a great offer from both and accepted one of them.<p>I strongly prefer a coding project to a whiteboard. It is still a bit artificial, but it is way closer to my actual work.
It was not really a whiteboard exercise, but I once had an interview at which we went through some of my previous work (code-ish) on a whiteboard. I was mostly for structure, and I think that's a good example. Also there was a good relaxed atmosphere, so it was more a point of discussion. Got an offer.
I'm seriously tempted to make one of our technical interview questions "you're creating a technical test for role XYZ, how would you structure it" and see what the candidates come up with!<p>Would be interesting tbh.
As a follow up to the first interview, we give promising candidates a quite simple task to solve at home and then send back via email the next day. This is used both for some basic evaluation of developers skills (whether they actually solved the problem, did they catch the small oddities hidden in the data set, did they document and write tests, etc.) and as something to discuss during the second interview, in which the candidate talks to one or two developers.<p>I also did a second code test, which I got to do alone on an offline laptop. The test had a time limit and it was designed in a way that you should NOT be able to finish it on time. This was communicated to me several times before I actually sat down in front of the laptop. The goal with this test is to see if a person can solve problems under stress, and if the person writes decent code that works, or just hacks something together and moves on to the next step - leaving a trail of bugs.<p>Overall, I think this has worked out great for us, but it might not be a good process for everyone.
I don't see a problem with whiteboard interviews. I've been to a lot of interviews where they will ask me to explain an architecture and I ask <i>them</i> to do they mind if I draw it out while explaining it.<p>I've spent so much time in my career explaining architecture it's second nature for me to diagram while I'm talking.<p>During a whiteboard coding session in an interview, I would do some code and some pseudocode.<p>But at this point in my career if I saw that the interview was focusing more on coding than architecture/development process/automated testing that would be a big red flag.
If it lasts longer than 20 minutes, you're doing it wrong. But more importantly, are we talking about hiring a security expert? Or hiring for a product development team? Or hiring for the devops team? Context is rarely given in the "whiteboarding issue" discussion, e.g. at HN. I currently hold candidate interviews for a solution architect role, and I certainly don't want to hire someone who can't hold a whiteboarding session with a client or their partner's SME.
Whiteboard should not be the focus. If interviewer just shared whatever technical problem they're trying to solve and asked the interviewer to share their insight as a peer, then it's up to the interviewee to use the whiteboard or not. Frankly, I think this is best done over email so interviewee has the time to think about the problem.<p>In short, companies should approach interviews like free consultations with an expert or peer.
I personally love whiteboards...but only for discussion of ideas. But interviewers seem to use it only to dock points.<p>"Oh this guy solved the problem on the whiteboard with good syntax but he uses new and delete. Must be a bad programmer."<p>I think docking points on whiteboarding just reflects how bad interviewers are at judging skills, possibly because they themselves suck at self-awareness and skills beyond their domain.
This is great. I would add <a href="https://toggl.com/" rel="nofollow">https://toggl.com/</a>, but I'm just a silly marketer and don't have a github account. btw not affiliated with toggl whatsoever - just a fan :D
It looks like many companies in this list use the take-home project approach. The take-home project however is not a replacement to the whiteboard session, as they're not meant to screen at the same level. Once you're given a take home project, you're almost in. It happens when the recruiter really likes the person and wants to dig further with a real life scenario to see how that person would perform.<p>The whiteboard session is a way to spot people who can't code early in the process.
I work remotely and sometimes interview new potential hires. Does anyone have some suggestions for how I could imitate whiteboard questions without actually having a marker and surface available to me or the candidate? It's a little awkward to ask them to write on a piece of paper and angle their camera so I can see what they're writing! Is there any good software that can emulate this?
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....<p>If you really want to test a candidate, give them unlimited time, a "real problem" and something that they don't know.
Using the presence of whiteboard questions as a metric for interview quality seems rather pointless to me.<p>Whiteboards questions can be very good or can be very bad or anywhere in between. Just like any interview question in general.<p>I for one prefer whiteboard questions to generic open ended personal questions.<p>Good whiteboard questions can quickly assess whether someone knows the basics of programming or not.<p>Open ended questions only judge one's ability to tell stories.
I haven't used a whiteboard in five years. Some people seem to love them, but I just don't get it - in any situation I might use a whiteboard for, I have more effective tools that I can use instead.<p>There's nothing like having to pull out your phone and take snapshots of a whiteboard because people can't be bothered to use something persistent.
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.<p>Sure some bad companies expect you to be able to write something very specific on the spot, but thous are pretty rare imo.