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 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.
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 follow.
- There is no context driven autocomplete or quick method lookup. If you spend your entire day coding in one language and have done so for the last >3 years you should be fine. If you code in multiple languages and spend time with other tasks (devops for example), you might not realize how much you rely on this.
- The white-boarding process works well (given previous two caveats) if you code in a linear style. If you code iteratively the whiteboard is not your friend.
My recommendation to someone starting the interview process. Go buy a small whiteboard and use it to code solutions to interview questions you find online.
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".
This, to me, is the most important point. We make such a big deal about making sure our tests actually test the thing we care about; why aren't we doing the same thing with our interviewing processes?
I absolutely agree that whiteboarding is a skill that requires practice. That said, with a reasonable interviewer, the first couple things you're discussing really don't matter. The trick is to understand that no one cares if you're actually writing working code, and that the important thing is communicating your intentions and process.
> There is no insert.
This really isn't a problem. If you need to insert a line, in most cases you can just draw an arrow and then describe what you forgot to do there. Code may not even be necessary. Anyway, an arrow is fine.
> There is no context driven autocomplete or quick method lookup
Again, not really a problem. Just say "I forget the method name here, I'm just going to assume it's called 'append'" (or some other appropriate name). No reasonable interviewer cares in the slightest as long as it's clear you know what you're doing and it makes sense.
> If you code iteratively the whiteboard is not your friend.
This is absolutely an issue. Everyone codes iteratively though. Successful whiteboarders learn to do the iterative part of coding verbally instead of in code. You talk through the algorithm you're going to implement, and refine your plan in words, and then only when you've got a solution you're happy with do you pick up the marker. As a side benefit, this demonstrates your thought process much better than coding would. Actually, this is just a better flow even for development on your own computer. Once you develop the skill, you'll find that a little more planning time before you touch the keyboard almost always leads to faster implementation overall.
> The trick is to understand that no one cares if you're actually writing working code, and that the important thing is communicating your intentions and process.
This is absolutely not true. I've interviewed at many major companies (Google, Apple, Snapchat, etc.) and they all say at the beginning "Make sure you have working code". They don't necessarily care about syntax errors or spelling errors, but they absolutely want working code.
> They don't necessarily care about syntax errors or spelling errors, but they absolutely want working code.
I'm not sure how code with "syntax or spelling errors" qualifies as "working code." The fact that they don't care about those things is pretty much the exact thing I was trying to communicate.
Other things they probably don't care about: unimplemented placeholder functions (they might ask you to go back and fill those in if they thing it would be informative and there's time), or misremembered function/method names (though it's important to communicate that you know you don't remember).
I mean, obviously they do want code that demonstrates a well thought out solution to the problem. But no one expects that you could just copy it into a text file compile it, and have it run - that's what I meant when I said no one cares if you're writing working code.
As always, some companies spoil it for the rest; whiteboards are fine but the crazy Hackerrank kind of interviewing, coding, on a whiteboard, correct algo's you studied in uni 10+ years ago and so on got a lot of people annoyed.
Nothing wrong with having someone sketch an architecture or a brief plan-of-attack on a whiteboard. But demanding someone to write a correct Bailey–Borwein–Plouffe implementation (I read a few months ago someone got that question in an interview; find the nth digit of PI efficiently as you can. How useless.) or something from their brain without a computer is just rather insane imho.
Seeing if they can write code would be actually writing code. Behind a laptop with access to internet and time to do it. Also; previous work.
Dismissing someone using an objective/concrete criteria such as a failed programming test is not problematic.
On the other hand, if you dismiss someone because "is not a cultural fit" or some other subjective reason, the person can sue you, accuse you of discrimination and challenge you to prove your point over a legal mine field.
This point is over-parroted. Anybody can sue (almost) anybody else over (almost) anything in this country. A butthurt applicant is not going to be dissuaded from suing you, if so inclined, just because you gave them an "objective" reason.
I can't tell if you're being facetious or if you're really that naive.
No company that I have worked for has ever said, "You know what? Let's look at the resumes of previous applicants, call them up, and see if they are still looking for new jobs." Every vacant position is always filled by direct, active applicants. Even backchannel applicants have to send a fresh copy of their resume to someone, so that it can be added to the applicant tracking system.
Tech resumes have a short shelf life. If the person is any good, and actively seeking to change employers, they will already have a new job by the time you have an opening for them. And if they are constantly doing a low-key, back-burner search, just to stay tuned-in, they will probably apply again to whatever you advertise, if they are still interested in your company.
The only companies that will keep your resume forever and call you back later are recruiters.
It may be that I have never been considered good enough to get hired, but not quite as good as the people they chose to hire on the first round, but for most companies, I either get an offer or I never hear from them again. Those still willing to communicate after a no-offer have never contacted me again regarding another open position. I admit there may be a theoretical nonzero probability of this occurring, but it has a lot of zeros between the decimal point and any other digit.
I'll offer a counter amnecdote: I submitted a friend's resume, he was interviewed and my boss liked him, but his boss didn't (I don't know about other feedback). Some time later, we had a new opening with some urgency and my boss asked me to see if he'd like to interview again; he was hired after that round (boss's boss did not interview him)
I had a company call me up years later based on an old resume. I turned them down, but mainly because I only applied to them because I was desperate (don't like the company) and the job they were offering sounded pretty lame.
I can't imagine it's a very successful tactic, and it probably only happens when they're desperate.
No insult was intended. I intended to disparage the hiring processes of the companies I have previously encountered. Your experience appears to have set different expectations than mine. Perhaps it is a regional difference?
I work mainly with companies with a significant physical presence in the US Midwest and near-South. The furthest west I have ever interviewed was in Denver.
A significant number of the companies I have interviewed with lack even the ability to respond to a follow-up message the day after an interview, so never mind contacting someone months later.
Ah right, in NL where I did most interviewing you are not allowed to ask a woman if she is or plans to get pregnant for instance. Not exactly a subjective reason, but I think akin to what you are saying.
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 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.
Of course, you need to test ability, but you should also accommodate people's preferences on the environment that they are evaluated in. You can negotiate whatever this is by speaking to them: they might have a Github with projects which they can discuss with you, or they might be happy to do a small project, etc. You need to keep your standards high, while also ensuring that they feel that they are able to do their best.
"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 many people who will offer their anecdotal stories of desensitizing themselves.
Being able to talk and interact with people is a part of the role. Software is not written in isolation - it is done best with a lot of collaboration and critical review of work. Being able to communicate and give and receive critical feedback are cornerstone traits. Good code is not written in isolation and giving and receiving critical feedback is not comfortable.
If I interview for those traits and qualities, I hope that I'm not discriminating against social anxiety but I spent 5 years in toastmaster's throwing myself in uncomfortable situations until I could come out of it.
I feel like interviewing is becoming this PC thing where we try to form to evaluate people in the way that is comfortable for them, where we live in a world where people need to break out of their comfort zone and learn to shape themselves into their environments. Go to Toastmasters, speak in front of people, keep going and you'll improve your skills - yes the soft ones too. You'll become comfortable - you will - ask anyone who stands and speaks confidently in front of you in those rooms if they were always that calm and composed while speaking in front of people. They were not and they learned to speak 'off the cuff' on topics they were not prepared for or subjects they didn't expect in there.
Maybe I'm alone in my thoughts but I'm looking for people who will grow. I want someone who will stand strong if I give them a critical code review - I want someone who will hang their ego at the door and be able to talk about what we're working on objectively.
If I'm still coming off too hard on this, what if I say that it's a consulting company that I'm hiring for and that the staff will be in front of customers who will interview and drill them every day?
Ultimately, we can grow and change. I know we can because I have grown and changed. I want my staff to have a growth mentality, not a fixed view of themselves.
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.
> I hope that I'm not discriminating against social
> anxiety but I spent 5 years in toastmaster's
> throwing myself in uncomfortable situations
> until I could come out of it.
That is impressive and I believe you, however I don't think exposure therapy is proven to work in all cases for everybody. Either way, I don't think that we should require everybody to have 5 years of practice in whiteboard interviews before they can get a job. That can't be right.
> Maybe I'm alone in my thoughts but I'm looking
> for people who will grow.
Perhaps they would like to choose what they spend their time on. Sometimes introverts don't mind being introverted, and don't want to take courses on "how to be the most exciting guy in the room". They like their personality as it is. They might still push themselves to grow, but they choose to grow in the areas that they care about.
>>Being able to talk and interact with people is a part of the role. Software is not written in isolation - it is done best with a lot of collaboration and critical review of work. Being able to communicate and give and receive critical feedback are cornerstone traits. Good code is not written in isolation and giving and receiving critical feedback is not comfortable.
There is a difference between collaborating and receiving critical feedback from a fellow coworker, and being evaluated by an interviewer (or worse yet, a group of interviewers) who might or might not offer you a job (since your livelihood depends on that). That's why people who are typically comfortable working with others can become extremely anxious during whiteboard interviews.
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 go. More often, the interviewer asks about complexity only so that they can compare to their own solution copied from the best of a hundred other candidates and then hand-tuned for days. It's a gigantic ego trip, and not even a fair fight. Candidates can see that, and it tells them a lot about what kind of person the interviewer is. Hint: it's not a pretty picture.
I was fortunate to go through an interview process recently where I had to do coding interviews, and it wasn't just a big ego trip. Second time in thirty years, vs. dozens upon dozens (all passed) of the worse kind. I could tell the interviewers had actually been trained, because I've been on the other side of that desk. They didn't care about the code I wrote, so much as how I approached a new problem, dealt with edge cases, explained various decisions, responded to challenges, etc. That's how it should be, but doing this stuff right is hard. Very few who pretend to do it have invested the time to do it properly, so they get results that are worse than useless. That's why there's so much hatred of the approach. Most people have never seen this kind of interview done right, and it's not their fault that's the case. It's on people who went from copy-paste programming to copycat interviewing.
> 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.
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.
My father often told me that there are 2 ways go get rid of a bad worker. Fire them, or promote them. Eventually, they'll be promoted into a situation where they'll have to be fired.
I don't take "multiple promotions" to mean anything in itself. If they can talk about what they did and why, then I consider that they're probably good at their job. And that's the point of interviews, IMO.
Government / military like to promote problems away. Helps to keep the person away from the work that needs to get done. The good thing about that sector is that there is a lot of room for lateral promotions to other offices and so then they become someone else's problem.
I suspect the backlash is mostly because an interview is already stressful. Then, when you ask someone to code with a marker, all of the muscle memory associated with how they usually code is gone...adding to the stress. You may be missing out on good candidates that just don't "whiteboard well".
Of course, some interviewers are better than others, and can manage to do things to make it a reasonable experience. You outlined some of the things that you do that make it seem like you're in that camp.
I'm not sure there's any one-size-fits-all interview technique that is universally better than others. The homework approach seems popular here, but then there are others that are put off by it. Probably the best thing is an interviewer that's smart enough to change gears when they sense the approach isn't really testing the candidate's skill.
I think the primary problem with this sort of interview process is that most companies don't hire enough people to discover whether or not it actually works, plus an interview is so much of a multivariate problem that you'll never really know which part of the process is broken if a bad hire gets though. And that's compounded by the fact any false negatives (great candidates who would have fitted in but got rejected) are clearly never going to be discovered.
The problem I have with whiteboard coding in interviews is that there just seems to be better alternatives. Using a computer as other people have suggested, but also just talking to them you can figure out if someone knows how to code. If you ask someone how they'd check if a number is in two arrays you can immediately tell a developer from a non-developer (or an inexperienced developer) by the language they use and the questions they ask. If they mention loops then that's a bad sign. 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.
Why is mentioning loops a bad sign? The question is simple, and asks for only checking one value; that's a simple answer that, for one value, takes linear time, which is the best you can do (without assuming the array is sorted, but expecting someone to ask you if the array is sorted turns it into a trick question, rather than a real world one). I mean, yes, I'd prefer them to go to a library call for that, but I wouldn't expect them to infer additional complexity from how I stated the problem.
Sure, if someone were to start asking questions, finding out that we're doing this operation a lot against the same arrays, so it makes sense to rebuild them into a set, or we're doing it against only sorted arrays so we can do a binary search, or whatever, is great...but that's more interview technique, not actual coding skill. You're clearly asking a contrived problem, have provided no additional context (no business requirement is "search two arrays to see if a number exists in both"), so it's not really fair to assume a prospect will treat it as an ambiguous requirement that needs further refinement.
This is really the heart of the issue; you're not testing for basic coding ability, which is what you're thinking you're testing for; your own criteria is testing for whether they assume you're trying to trick them. Talking it out isn't testing for coding ability either; I've met people who could say "You would search through each array to see if you can find the item in question", and then literally could not code that correctly, in their alleged preferred language.
If you want to measure whether someone knows to clarify business requirements, give them a business style requirement. "We have an interface that allows users to provide a list of their favorite foods. We want to provide a way for users to compare their own list of foods with that of a potential friend, and see what they share". Okay. That leaves the underlying data structures up the developer (as they are in the real world), and describes a problem they can ask questions around.
...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 look like?') I expect them to question those assumptions. Expecting someone to go deeper in to a problem by finding out more is not "trying to trick them", it's a discovering whether or not they can do a fundamental part of any development job.
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 the value; expecting to do all that in five minutes so more complex questions can be asked.
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.
> This might go some way to explain my attitude about this
Yep. You're giving bad interviews because you're expecting someone to have the same previous recent bad experiences as you. I would never ask about the context of the problem you gave because it is so obviously just a quick coding test. You want questions about the requirements, you need to ask a question that feels like a real world problem.
> 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 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.
If you're already talking about coding a really simple problem like your array example, why not let them use a computer language to express a solution? After those 5 minutes, you can move on to richer parts of the interview confident that you're (probably) not going to hire a total bozo.
> 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 too hard to believe, without evidence, that someone can understand this level of detail and not know how to create working code. A parrot cannot engage in productive discussion, and aping speech patterns only goes so far. Plus, if they're so good at aping speech patterns, who says they aren't equally good at aping code patterns?
It's all too true. There are, in my estimation, probably twice as many people who can talk around in circles and make it sound like they know what they are talking about, as people who can actually knuckle down and get things done. There's a little bit of overlap in the Venn diagram there, but not as much as you might think, for whatever reason. Probably because the people who can actually do things are too busy implementing all the shit that the bullshitters get their teams on the hook for.
> Plus, if they're so good at aping speech patterns, who says they aren't equally good at aping code patterns?
One is a social skill; the other requires understanding. Even in a technical conversation, a very large percentage of the interaction is social if the conversation is taking place face-to-face. I have also worked with people who could talk the talk, but not produce the code. Without social skills, those people seem to fail from job to job while not really understanding that they are failing: things just inexplicably go wrong all the time. With social skills (which is much more common), those people bafflegab their way into being system architects, middle or upper managers, and executives, where a lack of detailed low-level knowledge is more of an asset that keeps them from getting bogged down in details.
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.
I've had interviews where someone expected me to write "compiles and runs code" in languages such as Python, Java, and C. I've also had interviews where "solve the program on the whiteboard with any language you feel comfortable with" means "exactly Java 5/6/7" because that's what the interviewer happens to know best.
I'm decent with a whiteboard. I routinely use one for brainstorming and discussing problems at work. I don't mind writing code on a whiteboard, even specific language code and including stupid shit like semicolons. I also understand that despite the fact that I can do it (and even enjoy it), it's a miserable experience for some people and expecting everyone to remember minor details that their editor/IDE takes care of for them isn't looking for the right thing.
I've got pretty complicated exercises in whiteboarding sessions: some problems with graphs or dynamic programming. The way how I solve those in my daily work is totally different to the way I go in 45 min whiteboard interviews: in 45 min you always have to do it in top-down manner, otherwise you will fail by writing non-relevant parts of the code and running out of time. I usually prefer opposite: bottom-up approach.
It's a skill. Very artificial and very dumb to my opinion since you never work this way, but interview supposed to test how you do you work.
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 another one, etc. If you feel like my skill set is what you're looking for, then bring me in and then we can see if we're a good fit for each other. If you don't like what you see, then don't bring me in - it's really that easy.
Having one or two whiteboard examples will never, ever, show someone the depth of your skill set. You have to look at their code, which will give you insights a whiteboard interview never will. All the things you mentioned about "basic skills" are obvious when you look at someone's code. Did they use classic or prototypal inheritance? Did they know what closures are? Did they use a factory pattern? Are they using ES6 yet? What tools are they using for their projects? All this and a ton more simply from looking at their code.
And if you're a developer, you should have an account on codeplex, or github, or bitbucket where interviewers can go look at what you're working on and the stuff you're building. It completely cuts out the "coding" part of the interview and should simplify the whole process.
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
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.
I say this from the position of someone who has side projects on their own.
The general feeling that an engineer can't be any good without working unpaid outside of their job seems like a self inflicted and unnecessary cultural norm we've adopted as an industry. I can't think of any other industry where someone who goes home and doesn't practice their craft after hours is looked down upon as much as it is in software.
I don't have the label for it. It's similar to how employers want to hire developers for junior pay but don't want to provide any training and expect them to have taught themselves on various tools while lamenting the lack of skilled developers. Someone else in this thread mentioned the view of software engineers being viewed as artists who have to have a burning passion for their craft and I think that's bullshit.
Yea there are always guys who actually have that passion and enjoy programming as a hobby, but they are the minority like any other profession. It's become some sort of virtue signaling. I've talked to a number of devs who go through the effort of having publicly available work to show off who have confided to me that they do it just so that prospective employers feel that they are passionate
A business wants to hire you to solve business problems. Coding is the manifestation of the solutions. To me the white board session is to understand if you can take new problems and understand them enough to sketch out a solution. As a hiring manager, I'm glad you've written code before, I want to understand on a day to day basis if you can transform business problems into solutions.
At most of the companies I have worked for, the difficult part of my job is taking the pre-existing code that barely works under the old internal proprietary framework and rehabilitating it into the new internal proprietary framework with a bare minimum of new development.
Showing off that I know how to write (or recognize and copy) good code from scratch does not signal for that. I can't tell you how many times I have had to code something that is objectively incorrect because the old version did it that way, and the customer doesn't want the new version to be different.
The problem with the whiteboard interview is that you can't show an old, crufty code base on it, and ask the candidate to sketch out how to implement a simple feature request without overhauling the whole thing to use industry best practices. And you can't show an existing relational database schema that is pathetically ill-designed and ask about a new report for the customer. Those are the sorts of problems businesses have. They don't suck it up and pay the big bucks for a software pro until after the amateurs have already tried fixing it with an Excel spreadsheet or an Access database. And they don't want you to mess up the solution they already have, no matter how much baling wire and duct tape is holding it together.
Not everyone that can write code can also work well within an existing codebase. The only situation in the wild that I would trust to indicate that skill for my company is someone who actively contributes to an open-source project with a lot of other active contributors. A one-person side project that shows off everything you can do all by yourself won't reassure me. In fact, if it's too good, I might be worried that you will want to overhaul working code just because it's really, really ugly, and you can detect multiple code smells when you look at it.
>> To me the white board session is to understand if you can take new problems and understand them enough to sketch out a solution.
Honestly? This should be ferreted out in a screening interview.
As someone who's hired developers both as a manger and a senior dev, you know what's really important to me? Knowing where your head is at as a developer.
What I really want to know is:
1 - When shit hits the fan and you're buried under a mountain of stress, how are you going to handle that? Are you going to fight through it, or just give up?
2 - I want to know if you're open to other approaches to coding? What about other frameworks or tools? Do you believe there is one way to achieve a result, or multiple ways?
3 - Does your code have be perfect on the first try, or do you get something working first and then worry about how sweet the code looks later?
4 - How do you feel about fixing bugs? What if I made you fix bugs for 6 months before you started working on any project, how would you feel about that?
5 - Do you have the courage to stand up and say something if you feel like it will negatively impact a project you're working on?
Knowing how to solve basic coding problems at a whiteboard can't substitute for an impending deadline and tons of work that needs to get done in two days. I'd rather have an average developer who can handle a shit ton of stress and get his job done, then some rock star developer who folds like a lawn chair when things get tough. I want the developer who sees a tough deadline as a challenge, rather than the dev who whines constantly about it. You can't figure that out by standing at a whiteboard. You need to sit down and actually talk to the person to get to that stuff.
We do technical interviews on conceptual levels. One manager, one HR, one programmer (not always all three at the same time) and the interviewee.
We ask them about their experience with the tech we use / plan to use and test what they tell us with specific questions. If you tell us you know ASP.NET, I might ask you to describe the default routing or some specifics about razor views. If you tell me you are a git expert, I might ask you about interactive rebases and cherry-picking to find out when and how you'd use them.
General know-how is usually more viable than the ability to write working code in a pinch. The closest thing to a whiteboard test we have is giving you a page of code to ask you what's wrong with it (although, we don't do that often).
My office is a satellite of a larger one in Austin; we provide laptops for candidates to use for the "remote" part of the interview, when they interview with someone in Austin.
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. Getting a chunk of source code in an email isn't representative of that. (At worst, they paid someone to do it for them; at best, you have no idea what their approach was. Somewhere in the middle is copying and pasting most of it from SO.)
> 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 synchronously while actually writing code.
> 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.
This is exactly why I do this kind of stuff as well when interviewing. It's not about syntax or the ability to recall (regurgitate?) a function, but how does someone approach a problem and where can the conversation go from there. If you sent someone pre-work to write an array matcher, you'll see a final result, but not how they think through it, and you'll miss potential queues to further the conversation.
I have used both ways, and i would say the candidates in general respond better to using the whiteboard.
I do ofcource not require syntacitly correct code or anything like that. Im looking for ideas not if they are a compiler.
Using their own computer way to many struggle with creating a new project or other basic things. And that dont make them comfortable either. It also takes much longer then using the whiteboard.
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 whiteboard exercise and been burned by this; never again. The whiteboard is a filter to eliminate people who misrepresent their abilities.
>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.
So you test their ability to write code on the whiteboard.
I was once programming with pen and paper too (only had access to computers at university). They I bought my own computer.
Don't know why this comment is downvoted, because he has a point. Writing actual code on whiteboard is different, unless it's pseudocode without any syntax rules and standard libraries.
I'm not a newbie (like, 15 years coding). But I haven't even bothered to properly remember standard libraries peculiarities - since they're different across the languages anyway, and with modern software stacks (that are quite diverse) it's not unusual to write Python but do some C or C++ one day (speed-ups), detour to JavaScript, try out Elm, then have a day patching some Go code that an useful tool is written in, then go learning some Elixir. Is it strpos(substring, string) or strpos(string, substring)? What does base64.encode(blob) returns, again, ASCII bytes blob or a text string? Which module/header file contains/exports that symbol? Maybe I'm doing it all wrong but I honestly never remember such details that for longer than a week or another - a proper tooling always hints those kind of things to me, so I don't even recognize I tend to forget them.
Why does everyone assume that you're asked to write perfect code on a whiteboard? I've been through 15+ interviews and have never been asked to worry about method names being right or signatures of methods being perfect and such. Most of the time people are amicably against me worrying about it. This isn't an issue.
I think, it's not an assumption, but a fear that this is the case.
Adds some extra anxiety as interviewee still worries about their code being correct or not. No one wants to risk being frowned upon just because they've messed up some syntax fine point. And since people are different, sometimes it really happens.
This can be avoided if interviewee's specifically told they just have to write algorithms in pseudocode, but it's not how it always goes in practice.
Because sometimes you are expected to write working code on whiteboard. Once interviewer was typing code I wrote on laptop and interrupting me on errors he had.
You'd better be looking for psuedocode, because if you're looking for syntax, no strong programmer with experience is going to take you seriously.
Honestly, whiteboard interviews are for lightweight startups with very little programming knowledge. You should be looking at logic, not syntax. You should be looking at how the person thinks, not if they can memorize a specific language to do a simple task.
Have you ever interviewed at Google? They care about syntax, psuedocode will not cut it in the interviews... and Google has a lot of strong programmers.
Google has the name to attract strong programmers. I'd like to see stats on how few (or many) strong programmers their interview process misses. Especially when that interview process is used at a company without such a huge name.
It simply selects for people who can write a simple code unaided in an interview situation while somebody is watching every letter you type. Many people don't have a problem with that, others have.
I'm not sure that's true (in terms of explaining the backlash against whiteboarding specifically). From the page:
"The companies and teams listed here instead use interview techniques and questions that resemble day-to-day work – for example pairing on a real world problems"
I would contend that if you're doing pair programming with a candidate, you're looking at people writing code in an interview situation while somebody is watching every letter you type.
In fact, I think hacking on actual code is worse than whiteboarding: everyone knows how to use a pen and board, but don't do so frequently. Different candidates being placed in front of the same computer and IDE, however, may be vastly more comfortable or not - they may know the bindings, etc. If they're not the "driver" in the pair, they still have to grok the codebase and the problem quickly.
Whiteboards may be abstract, and people may focus too much on algorithms with them. I don't think that there is much fundamentally different about pairing, and I would have more reservations with pairing personally.
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.