VP of Engineering at Eaze, previously CTO at Getable and engineer at Yammer.
No, not at all. Whiteboard interviews test one thing
well: How well does a candidate code on a whiteboard.
Engineers on my team never have to code on a whiteboard
(whiteboards are really bad at running code), why would I
make candidates do something that I don't ask the
engineers already on my team to do?
What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams?
I hate this concept that if it's not typing code into an editor then it's not "real work".
I absolutely communicate with my coworkers using a whiteboard and pseudocode. I reject the idea that being put on the spot is necessarily "artificial". To the contrary, I think that the number of engineering jobs where you can assume you'll never be put on the spot or have to communicate complex ideas verbally or visually is relatively low.
Now if this particular skill isn't interesting to an employer and they'd rather spend the time talking about some other candidate capability, that's a whole different story.
Whiteboard interviews rarely test the ability to communicate on a whiteboard because the interviewer knows the answer they are looking for and the presenter does not.
If you defend whiteboard leetcode using this excuse you are deluding yourself and you are part of the problem. The only thing the modern FANG interview hires for is people that can solve algorithms problems in a silo under pressure. No checks for software engineering skills, collaboration skills, testing skills, reviewing skills, and on and on...
The whiteboard interview is why so many engineers unexpectedly suck.
They you are asking the wrong questions. I use whiteboard for developers, and for junior developers I give them a simple task such as reverse an array, turn a string into a palindrome (and explain what it is if they don't know). If they want to be a developer they must be able to solve those simple tasks. I don't really care how, as long as they think loud. Then I use it as a starting point for enhancement discussions, perhaps stack/heap questions, recursion, assignments ect. During all this I coach them, teach unknown concepts in simple terms - this is what they can expect when they ask their mentor a question so in that sense they get a feel for us too.
Some argue that it's still not good, and that we're filtering out people that work best alone. That is true, but that is by design. We work as a team, having 10 individual developers not working together unless forced is an architectural nightmare.
I'm not asking them to impelment van Emde Boas tree because I spend countless of hours implementing and analyzing it getting my degree. I ask them to turn a string into a palindrome, or return the sum of all even index in an array of ints, ect. They're free to ask all the questions they like. It's a litmus test to see if they know simple programming, akin to seeing if a contractor knows how to drive in a nail using a hammer.
Is it high pressure while your future career is on the line? Absolutely, but they are not special snowflakes, and it's the case for any interview for any kind of position. I'm not going to throw thousands of dollars after someone just to figure out that they have in fact never written a functioning for loop.
The reason many engineers unexpectedly suck is because it’s a high paying job where performance is difficult to measure let alone predict.
White boarding interviews are a symptom of the problem, not the cause of it.
If the interviewer leaves frustrated because they couldn't solve anything and it was a mess, or the question was formulated terribly, or the interviewee was under prepared, etc etc, then it provides a lot of insight into the capabilities of the interviewee. It almost provides more insight into the qualities required of a developer than just putting them on the spot.
I think it's safe to say that being put on the spot in front of people you don't know who are judging you is quite different from being put on the spot in a team meeting with someone from product who will watch your demo of a potential new project/idea/concept.
We've never rejected somebody for having a "bad" answer, because they were able to at least talk about what they're doing. We have had people flat out refuse to even try, and that seems like a pretty big red flag.
So it seems to me entirely reasonable to still be nervous.
Mind you, I don't have a better answer, but I don't think just explaining that suboptimal is ok and it's a discussion really helps.
Picking on whiteboard code for not compiling is not good interview technique. But it's also a common enough failing that it's hard to say a bad interviewer in that regard means a bad workspace, unfortunately.
The only place I’ve worked that was “good” instead of “treats people poorly but where else are they going to go” was a small, boutique financial company.
Small companies that are randomly led by non-dummies are the best, but are exceedingly rare. Out of the vast majority comprising the other stuff, it’s mostly all so miserable that you’re doing yourself a favor to skip it unless the pay is some dramatic increase for you or you otherwise have some emergency requiring you to take some job.
(And yeah, the pay makes a difference. Not a lot of places where you can make a few hundred thousand dollars a year.)
(I’m making a distinction between the idea that a job “is fine” where one “is happy” merely because the culture is at least not worse than elsewhere while the pay is better vs actually feeling positively about one’s company’s culture and corporate behavior.
For example, my friends who work at Facebook are “happy” with their jobs, mostly because of pay and because they know if they switch to other companies, politics, corporate misbehavior, etc., will just continue. But these same people tell me frequently how sad, upset, soulless, disappointed they regularly feel because of their employer.
That feeling I think is extremely widespread in tech, almost all employers. That’s the only part in my viewpoint that matters for whether someone “is happy” at their job, and it’s that type of bad culture I think can be easily flagged by little stuff, like bad whiteboard interviews.)
Nobody has any idea what’s going on; nobody has clarity. And when someone does have clarity, middle management is only interested if they can set it up like a battery to harvest credit from. If they can’t, their incentives are usually more aligned with intentionally abusing process to “manage out” innovative people.
the one thing i'd add is that i do take particularly thoughtful / empathetic interview processes, interviewers who actually know and understand the question (rarer than you'd think), etc. as a fairly strong signal, as those sorts of things don't just happen by chance-- they are the byproduct of a culture of thoughtfulness (and thoughtful people tend to be thoughtful about most things).
Ya I did not get that job lol.
Also, generally, if I'm whiteboarding in front of my coworkers/team/etc. I'm discussing something I've thought about for more than the few moments I have to digest the question while standing at the board during an interview.
> Can we assume I know how to do argument checking?
I would probably question you at some point about a particular value of an argument and almost all candidates will get points for thinking out load that of course a NULL would get it crashing and that a simple check could stop it. Then it leads to discussion about how it should be handled. Sometimes a NULL means the program should cast an exception, other times it should just return without any side effect.
IMO the hate for whiteboard questions is really a symptom of poor interview technique.
Granted, I will give you that optimized code has definitely been important. One of those interviews even had me use a bit array (at least I think it was that) to efficiently a store a list of booleans but at least they gave me the relevant function calls to use an already implemented one.
Right. And a competency based interview goes better if you have a perfect example for every question. But it isn't an auto-fail if some of your answers are mediocre
Personally though - I'd rather hire someone who is able to properly communicate their thought process over an imperfect solution, than someone who was unable to discuss/explain the perfect solution they scrawled down.
When I give interviews candidates often say they don't remember some API. I tell them I don't care and they should make something up and I'll figure out what they are doing from context. The only time this burns candidates is when they clearly don't understand an ADT well enough to give it a sane interface.
In my most recent on-site interviews, my interview would be in a room with full floor to ceiling glass windows, the next interviewer would come in, ask one or two personal questions, and then either cut me off after a couple minutes or just simply say "we're going to move on to the whiteboard now, do this". Meanwhile people are walking by staring into the room, looking at the whiteboard, etc.
Which is just too rigid, IMO.
When I interview a candidate, I want to know that they'll be able to work together with myself and my current teammates as a team. So I would rather do something similar to what you described.
Fizz-buzz tests have their place, but I think an onsite interview is past that point. In general I have found that white board exercises don't allow me to either understand or convey how I can apply my expertise to provide value for the organization.
I've had my share of the second kind, which were without exception some of the most unpleasant interviews I've ever gone on.
Except at the end of the day this is an interview, you are judging their answers and evaluating their performance. I have been part of white boarding sessions like this and it does not reduce anxiety and still feels completely removed from what I actually do on a daily basis.
We at least on a weekly basis somebody has some small problem they need help working through, it generally ends up being diagraming or pseudo-coding to figure out the best approach. If somebody can only participate by hiding in a corner typing out code, then the process worked for both sides.
If only all interviewers were like you.
I’ve interviewed at Facebook as well and although the interview was not successful I have never been nitpicked about syntax and compilabiltiy/runnability of my whiteboard solutions. I came off with a very healthy appreciation of the way they try to engage the candidate and reduce stress.
I highly doubt a normal engineer is going to be giving a demo to their team with high stakes in the first three or so months. I understand if they're possibly a senior engineer, architect, or lead of some sort because they were probably hired with a plan to spearhead a specific project.
I'd say in the average case a new engineer will have enough time to at least break the ice with their new team before being put into a high pressure situation.
Nope. There was a great submission a few years ago about a guy who applied to two categories of jobs: management and software development.
In the SD roles, everything was oriented toward rejecting him. Any possible "red flag".
In the management roles, the interview was focused on finding areas where he could contribute to the company.
Whiteboard interviews are a problem in and of themselves, and the propagate terrible attitudes into the rest of the interviewing process.
If communicating ideas is part of your job, I'd bet any amount that you decide what ideas you want to communicate well before you do the actual presentation (or other physical delivery of the ideas).
When I get hired this way, I always feel a little bit of guilt because I know they actually hired somebody else.
What can be done? I’m not sure, but I can say one thing: my level of discomfort is multiplied by the number of strangers in the room. Does this ever get considered with interviews?
I am far more comfortable coding in front of 1 or 2 people who each give me a little bit of background about their coding experience; just so I know. If they are experienced engineers, it’s probably not going to change what I say aloud, but it just makes me more comfortable. I guess more overlap of technologies in our background does help. It’s nice to not feel pressure of worrying if my solutions reflect general programming conventions enough to be language agnostic. I have never really used Java, for example.
If you want to test communication skills amongst programmers, I dunno...ask them to write something in coherent English. Or here's a crazy thought: ask them to document some code. I guarantee that 80% of working "rockstar coders" will fail (but not before whining, crankily, about how unfair it is that you would actually make them do such a useless thing, since, y'know...never actually documents anything IRL, dude).
Programmers like whiteboarding because it lets them believe that interviews can be reduced to purely objective functions, and because GooAmaSoftBook does it. They're too scared to deviate from the pack, lest people think they aren't as "elite" as everyone else.
I feel like we're probably at an impasse if I can't convince you that a whiteboard is a decent medium to communicate ideas around datastructures and algorithms, but I appreciate your point of view.
I can only say my experience, which I hope you will take into account as one anecdote. I don't read books about "cracking the coding interview" or do leetcode or hackerrank. I left school 14 years ago or so my stash of cs trivia/secrets/gotcha isn't particularly full. I've done whiteboard interviews where I come up with at best a naive solution.
And yet I've received offers for fairly senior engineering positions at Amazon and Twitter and (hopefully tomorrow) from Google. Most of the whiteboard interview isn't even around the code, although that's a small part. Most of it is analyzing the problem, discussing constraints, discussing tradeoffs, walking through data structure manipulations, drawing arrows and boxes, that kind of stuff. Some code, maybe 30% of the interview. I just keep having this experience where nobody wants to play the gotcha game, they want to know how well I can communicate while solving a problem and they think they get that information out of the interview (I agree with them).
That experience makes it hard for me to understand a viewpoint that believes that whiteboard interviews are about memorizing secrets in advance.
Every set of interview prep material I've seen from Facebook, Amazon and Google recruiters asking me to interview in the last 3 months has included links to things suggesting "cracking the coding interview" is a good start and pointing to similar docs otherwise.
Are you sure you're not just replacing one stereotype with another here? Do you think it's fair to say that 80% of people who do well at whiteboard coding value documenting their software so little that they'd be fail at it while disparaging the concept?
There seems to be a bunch of ingenuous assertions here that is characteristic of someone who doesn't think one should have to prove oneself. I'm at a FAANG and we don't even ask anything crazy hard for algorithms/data structures like Google or Facebook does, but our interviews still manage to be intense for technical and soft skills - they will challenge even strong candidates and one cannot pass the interview without displaying strong technical acumen or communication skills.
There is so much more to technical assessment than just coding. A whiteboard is just a standard medium for communicating ideas in a collaborative manner that still works the best for any sort of deep collaborative design when compared to any other medium so far.
Think how much you might actually learn about a candidate if your interview process replaced a day of solid whiteboarding with a code review, some pair programming, a session of documenting someone else's code, behavioral interviews, etc. It's almost as if you'd be treating them like a...person!
I think the complaint that programmers pretty much never have to think about code under pressure is a fair criticism. The whiteboard really puts you on the spot. But if it's your company and your hiring managers are playing a game of gotcha on the whiteboard, you need better interviewers.
Whiteboard coding interviews are one thing that I have to go out of my way to practice for and get better at over time when interviewing (ie over the course of a few failed interviews). I don’t feel more skilled or smarter by the end of the set of interviews, but I inevitably do better at these kinds of problems. Should the interview be testing my competency at day-to-day work skills or how well I’ve practiced my interview skills, because whiteboard coding problems only achieve the latter.
I do coding interviews in the following manner:
I select an interesting problem from a book. I personally complete the problem, measuring what was challenging and the time it took for me to complete the problem. I check the textbook solution, making notes of how my solution differs from the textbook's. If I like the problem, and if it fits with the development role, I invite the candidate to bring a development laptop, I give them a hard time limit of twice the time it took me to complete it, and have them share their screen while they attempt to complete it.
Afterwards we test their solution, I ask them some questions about it. I grade based on code taste, the number of hints they need, and their completion time. All candidates for a position are given the same question. Performance in coding interview is about two third's of the overall candidate evaluation. The ability to sit down and write good code in a time constraint manner is a very important part of being a developer.
First, your definition of "interesting problem" probably includes a lot of personal biases. What you find interesting probably touches stuff you've had experience with, but just because you've done work on say, customized implementations of binary search, doesn't mean it's a good baseline for all developers everywhere. Maybe they've worked on different domains or solved different problems and can't relate to questions you personally find "interesting".
It'd be much fairer to select a boring question that involves standard stuff that everyone has to face at some point in their careers, like string manipulation. And even then, it just involve normal transformations ('look for and remove special characters') and not wacky, HackerRank-style rules ('no two bs after cs but before as').
On the other hand, I think there needs to be some proxy for "how well does the interviewee navigate complexity?" Because a programmer who does it well is far more valuable than a programmer who doesn't, and there's high variance on this between programmers and between fields of expertise.
The systems design interview sort of gets at it, and whiteboard interviewing often tries to get at it. I feel like I've yet to settle on an approach I'm happy with.
You have a good point, I noticed this about myself as well. However, I don't think whiteboard interviews are special in that regard. I noticed that I got noticeably better at the "sit down and code me a simple web API endpoint" interview, and I got noticeably better at the systems design interview, and so on.
I do think that whiteboard interviews tend to lean very algorithm-heavy, which doesn't reflect the role's actual day to day. And practicing algorithm interviews really does feel like an inefficient use of time unless your role truly demands algorithmic proficiency (like if you're a graphics dev).
which also means the team might consist of people selected by using this metric. this is a good signal ;-)
It's not; I couldn't agree more.
In real life when using engineering "skill", not only am I not anxious/stressed by trying to write on a whiteboard, but I'm using my laptop, with my editor, as well as access to man pages, docs, and google to look things up.
In addition to the overemphasis of performance responses, I think "how much do you know from memory with 10 seconds of thinking" vs "how much do you know with 10 seconds of google" is useless. The only fairly complex datastructures I can perfectly describe from memory are the ones which I used most recently...
Perhaps it would be more effective to have the candidate whiteboard a concept that they are already familiar with, be it a high-level engineering principle or a system/solution they have built in the past. Attempting to solve a problem you have just been presented with AND communicating the solution effectively is a big ask.
I know my opinion is unpopular, but I sometimes do think I've figured out something other people miss. I think when it comes to whiteboard inteviews, candidates are often playing the wrong game. They think it's about gotcha questions and they think they fail because they didn't leetcode hard enough. I don't think that's true, they are just trying to game the thing that's easy to measure.
In my experience with the "terrible" FANG companies, it's not about gotcha questions. I get the offers even though I don't often find a non-naive solution. The people I'm in the room with really do want to see my thought process and they really do want me to communicate the tradeoffs with them. People don't fail the gotcha questions because they don't know trivia or because they forgot a detail from their CS classes. They fail the whiteboard interview because they see an unfamiliar question and say: "I don't know that trivia" instead of drawing out possible solutions and having a conversation with their interviewers.
But ... if you read some of the feedback from interviewers at "those companies" that rely on these interviews, they say the reason they failed someone is exactly because they "didn't leetcode hard enough". It is manifested as:
"Well other candidates got the same solution as you, they just did it 10 minutes faster"
"You missed an edge case, even though your core algorithm was correct".
This is a huge issue with these interviews. It's all too easy for interviewers to evaluate candidates based on how fast, correct, neat or "complete" you answer was. It's easy and takes no time.
That may have been a reason why I have failed some interviews but I feel like most interviewers are actually good about this and will say something along the lines of "what about this input?" where my code does not work and then I have that "oh shit, that won't work for that" and then I fix it.
I'm inclined to describe it as a sort of interrogation technique, you're offering a stimulus (the problem) and aggregating a number of reactions to form an opinion, and open up new lines of questioning. Very delicate work.
I think problems arise when unskilled interviewers present an excessively obtuse problem to the candidate, then read far too much into their responses (this approach is also easily "hacked" by those who've memorised common problems of this ilk). To stick with my interrogation analogy, it's the equivalent of screaming in the suspect's face, noticing that they gulp before shifting in their seat and scratching their face, then deciding that "they must be lying".
If you can't give me good examples from your past, I'm going to throw my own questions at you. I tend not to do coding on the whiteboard, though. Lots more boxes and lines and schema and system interaction-y stuff.
thinking and presenting are two separate skills, and, in my opinion, can rarely be executed at the same time.
What you're testing is the ability to discuss a problem with your peers. That is the critical thing.
Do the whiteboard but don't make the coding the standard. Don't get too hung up on the details of the problem.
Make the problem easy but fuzzily specified.
Clear and respectful communication is one of the most important skills for an engineer to have.
If you read the second half of my answer in the article I go into the communication side of things. In my experience there are better ways to evaluate a candidate's emotional intelligence and social skills than asking them to code in front of someone.
I've written code on white boards at work, and I've discussed about code on white board with colleagues or managers. It's not the same thing as during interviews. The schedule is never as tight, scrutiny is way laxer and the overall mood is completely different when I'm working with colleagues or even bosses.
I kind of understand why the BigCo's do it (they need a super rigid filter since they have so many candidates), but in their case they could select for people with the best pink leotard on interview day and they'd still get decent programmers, because their companies are in such high demand and they generally already control their markets (software, natural monopolies, etc.) and can afford to pay a ton so the competition would be cutthroat anyway.
In that case I would recommend reading the candidate's resume beforehand, look for prior experience publishing, presenting, or teaching and ask them about it.
Do write lots of sequence diagrams, block diagrams, ui sketches, arch diagrams and very occasionally someone might draw a data structure.
Whiteboard interviews where the interviewer says "it's actually `.toLowerCase()`, not `.lowerCase()`, you fool!", or "oops! You forgot to `position: relative;` the containing element that you `position: absolute;`d below!". you're not testing anything useful. Maybe if we were still coding everything on punchcards and using massive user manuals, but docking applicants for things their editor would highlight or one ctrl-r on the page would find is ridiculous.
This is incredibly common, and you tell the candidate in advance that they will be expected to give an n-minute presentation on a subject of their choosing (need not even be tech) so they can prepare.
Tell me this: when did a mob last ambush you at your desk and demand that you invert a red-black tree on a whiteboard that they happen to have with them right now? I'm guessing that never happens where you work. If it does then fair enough :-)
Ironically this leads to min- maxxers who ignore a good chunk of their courses simply to master leetcode. My smartest peers are ones who work on interesting projects and research, thus never finding time to grind interview questions.
Then there are also companies that expect your white board code to compile and have perfect syntax, which imo is very unreasonable.
You're 100% correct. We give our candidates the choice between working through a problem at the office (on the spot as you say) or doing a take home project asynchronously. Not everyone has the time to do homework, but not everyone wants to do an in person coding interview either. We try to stay flexible.
Also, we're growing fast enough that we're rarely comparing candidates. If we can hire both the apple and the orange (assuming both candidates are evaluated to be good for the role), we will.
For both the sr backend and devops positions, how important to the roles is familiarity/experience with your technical stack? I might have some of the skill set/experience you're looking for -- sr backend engineer, sr systems engineer, devops are all positions I've held -- but honestly I don't know JS, .NET, or Chef. Bluntly, I don't want to waste your (or my) time. ;)
<tiny>Also, I wish HN supported private replies</>
You name it, we are doing it.
In fact, if someone is too into their stack, we see that as a bad sign.
So I'd be super excited if you decided to apply :)
> I am a quote
This makes the quotation doubly-distinct, and still readable on mobile devices.
To the actual point I wanted to make: plenty of engineers at companies code on a whiteboard. They schedule a meeting, grab a room, and talk things out, while making notes, diagrams and sometimes even actually writing out some code on a whiteboard.
I hope nobody asks people to write compilable code on a whiteboard, but asking a person to talk through a problem and jot down some pseudocode doesn't seem like an awful thing to me. Communication is a pretty critical part of our job.
I had to do that at my last interview. I got through it ok-ish. The more interesting question was a more general system design question - how would I architect a system to do X, under constraints Y and Z. What would I do if a new constraint came up? Ok, now how would I make it more resilient? There, the whiteboards is just a tool I can use, not the primary focus.
But it's the interview equivalent of your driving instructor making sure you adjust your side and rear view mirrors before you start the car.
Honestly, we all might as well read chicken entrails because that would be about as predictive as our current interview practices.
Can't do that in a whiteboard session.
Vast majority of the technical problems have been solved and its delivery a solution to a business problem that is the most important aspect.
Yes, I've been turned down for jobs over the white board but I've had more positive results than negative.
My sister, a pediatric ER nurse would disagree with you. The interviews are largely behavioral and are a breeze. No dummy is wheeled in with head trauma, random "new" diseases aren't invented and asked to be treated, etc. The simple fact of the matter is if hospitals hired in the same way, they would have no staff.
I know it's totally anecdotal, but we've all heard horror stories about candidates who couldn't write a for loop; some of us have witnessed these things first hand. And yes, phone screens should be filtering out those sorts of candidates long before they start sweating with a dry-erase marker in their hand, but, well.
How likely is an applicant for a nursing job to flat out not know how to stitch up a wound, or to take a patient's pulse and temperature?
"I know it's totally anecdotal, but we've all heard horror stories about candidates who couldn't write a for loop; some of us have witnessed these things first hand. And yes, phone screens should be filtering out those sorts of candidates long before they start sweating with a dry-erase marker in their hand, but, well."
Yes, it is a failure of how you have set up your hiring pipeline which you are now band-aiding. The majority of those folks can be screened by one look at a resume or in the first 30 seconds of the phone interview. Other hiring managers in our company repeatedly had this problem until we got them to focus of the right candidate qualities and ask the appropriate questions.
Take for example your local symphony orchestra; they have the same problem where people with visions of "making it" show up not being able to play at all. Want to audition? Send us an audition tape and a check. When you show up for the audition, you'll play a selection from these pieces and be asked to sight read this music. It is ironic that for an industry that is in a sense so subjective that the gates in the hiring process are more concrete.
To make an analogy, the software world is akin to:
Interviewer: "I see you are interviewing for the 1rst chair violin. The 3rd chair tuba player is really into experimental music, he would like to transpose Vivaldi's Four Seasons into a new scale with 12.5 notes per octave with a slight progressive jazz leaning. Oh, and since we all know there is pressure in performing in front of an audience, you have 30 seconds to think before the 2nd chair begins to throw rotten food at you. Reaction to stress and all you know...here is your tuba."
"But I don't play tuba...Are you asking me to play tuba? Am I going to be playing this nutcase's new music as part of our program?"
"Sigh...you don't know music do you?"
"Here's a couple of pages of unfamiliar sheet music that a second-year student should be able to play. You have an hour to figure out how to muddle through it on an instrument of your choice."
People hiring musicians don't do that, because they instead prefer to give candidates 16 bars of complex sheet music, and expect them to play it perfectly during the audition.
The programming equivalent would be to give someone a hard take-home problem, let them stew on it, bring them into the interview, and ask them to type in their solution, from memory, into a text file, on a keyboard with a broken Backspace key. That they will then compile, run, and compare the result of to that of the other 60 candidates auditioning for the role.
Are you sure you want to do auditions, instead of interviews?
> It is ironic that for an industry that is in a sense so subjective that the gates in the hiring process are more concrete.
That's because there's fifty thousand correct ways to solve a trivial programming problem, but only 'one' way to correctly play second violin in Vivaldi Four Seasons.
Music is a subjective art. Playing music is a mechanical process. My iPod can play music. My iPod can't implement a sorting algorithm.
Not a significant enough majority, imo.
I have no idea what the candidate did in their CS undergrad. Maybe they cribbed all their work from their roommate. Maybe they went to a party school. Maybe they spent the last 4 years as a 'Senior Developer'
at FooCorp copying files from hard drives to floppy disks, and posting a few paragraphs a day on the company's WordPress install. Maybe they are an Architecture Astronaut who can talk for six hours about how great Haskell is at doing multi-manifold monadic trivariable entaglement, but has no idea how to do any real work.
Or maybe they spent the last decade building Bigtable and MapReduce, and Spanner, and TensorFlow at Google. I'm not an expert on Bigtable, or MapReduce, or Spanner, or TensorFlow, though - and I can't definitively, in 60 minutes, tell if the person I'm talking to is bullshitting me. I can't tell if they actually did any of that work, or they coasted. I can't tell if the complicated problem they are describing to me is actually hard, or if they are embellishing it. Even if I felt confident that I could make that conclusion, my opinion would be incredibly colored by personal biases.
Oh, I should check their GitHub, you say? Well, guess what - Jeff Dean - the guy who did spend the last decade building Bigtable and Mapreduce, and Spanner, and TensorFlow - doesn't have a GitHub account. Presumably because he has better things to do with his free time, then work on OSS.
Oh, I should hire fast and fire fast? Don't get me started on why that doesn't work...
Once you're an RN or an MD with all the appropriate qualifications, assuming you're not outright faking them, they can be reasonably confident that you are, in fact, a competent nurse or physician and move on from there.
We don't have that, and so we have to spend a lot of time making sure that a prospective candidate even has the basic skills and qualifications of a software engineer.
I'm not opposed to white-boarding, but to reinforce this point I'll note that I would have done much better on some of these problems when I was just out of college than I would today, because they were all fresh in my mind.
I assure you I wasn't a better programmer or employee then.
Not always a whiteboard, either; one of the best engineers I ever knew flunked a Google interview because of a situation where he had to write a bash script and read it over the phone to the interviewer, who apparently didn't transcribe it correctly on the other end. But "they only hire the best", you know, and their practices are rock-solid and proven.
I, too, have a side project I'd love to quit my job to work on, but I think it's less monetizable than an actual game.
I've _never_ seen someone, or have asked to participate in, some sort of whiteboard coding thing. Even with pseudo code. That just doesn't seem helpful to me, at all.
Actual Code? Not a chance. Portability, Durability, Efficiency - It's the worst of all worlds.
No comment on it being an effective interview process.
And interviews are not pressuring, they are simple. No hard desisions, no anxiety whether it is going to work. You in and 5 hours later you out.
an advice to candidate: when you've been asked to do whiteboard coding - run away. this is a negative signal.
* Whiteboard coding is awesome for software development shops that don't actually own computers or use punch cards to load programs.
* Shared coding environments with a time limit works well when you want to double screen for someone who can also diffuse suspicious packages that arrive at the office
* Riddles and puzzles are good when your workplace has a chicken coop, an office fox and you can't figure out how everyone can go for lunch without leaving the fox alone.
* Behavioral interviews are appreciated by candidates who took Psychology 100 back in school for an easy A.
* Take-home tests go over well with the huge population of talented software developers who can't find a job and have loads of time they want to spend decoding the operational cost of a bubble sort
The only thing I've seen that's at all realistic and effective is a very short, __paid__ project. I did a two-day one for Indeed (ironically one of the worst promoters of all this bullshit) and a 4-hour one for my current employer. The payment doesn't even have to be market, it's more important as a signal to candidates that the company values your time.
I ask for 3 things from perspective employers:
1. value my time like you value your own (both the number and composition of your interview steps)
2. keep me updated as to where we're at in the process and when the next stage/decision will be made
3. Move forward in the process in a timely manner. It should not take more than 2 weeks from when you initially contact me to the process concludes.
I've never gotten more than two of the above from a single organization, but I will someday, and I'm betting that a company that treats potential employees that well will treat actual employees better as well.
It's so simple to figure out if you're on your own and just play around with the idea. When asked on the spot I just kept thinking "hey these people want an answer NOW, don't make them wait" while feeling their stare, and couldn't figure it out without help.
Thinking about making this an algorithm, are we forced to use recursion?
If it's very short, then almost by definition it's useless.
That being said I've had great results from doing, say, a tiny consulting project, and ending up with full time employment. The best jobs of my life have followed the pattern of "am either offered, or I manage to ask/negotiate for a small consulting project" -> "before the project actually ends, am brought on full time".
My time is valuable. I see no reason to work on a useless task for free.
* Paid projects are appreciated by candidates who are currently unemployed.
They are all imperfect proxies due to various constraints.
I wish this project approuch was more common. It would probably be cheaper than wasting time on multiple days interviewing reality shows where people are voted out one by one like some companies do it.
Here's my attempt: https://youtu.be/6LHqrxrC6Uo
I solved the problem, with an IDE and a compiler. I communicate during the entire exercise. It takes me over 2 hours. Granted, I debug it, so that takes extra time. (Can't debug on a whiteboard!) I had to take one break. On top of this, I've solved this kind of problem before and it still took me more than the 45 minutes you're likely to get in a whiteboard interview.
And I try to cover all of the "hot topic" points I know the interviewer is thinking about: size .vs. time tradeoffs, iterative .vs. recursive, etc.
If I had to solve this problem on a whiteboard, in 45-60 minutes, with the bar being "it must run"....I would fail.
I guess that makes me a poor programmer. Instead, I'm a grumpy old man who is really tired of all this fraternity hazing bullshit.
I had to solve almost the exact same problem very recently. I find the best way to start is to just implement the easiest solution you can think of, such as the array approach you mentioned in the beginning. I did that in 5 - 10 minutes. We spent the rest of the interview optimizing and fleshing out the problem (e.g. let's not use an array, but there is only one "color").
Overthinking the problem straight from the beginning and potentially being unable to provide a working solution at all is probably the worst thing you can do. I actually had that happen in a previous stage of the aforemention interview, and had to "reset" by going back and implementing the simple solution before optimizing it.
Probably you got exhausted after doing all these preparations and debugging issues not related directly to the algorithm. I'm not sure the final solution is correct, it is not tested on a graph with multiple connected segments of the same color. It looks more like a convoluted way to count colors globally, discarding standalone colors, if I understood your solution properly.
Sure you COULD use a graph, but using a different code abstraction to represent the idea of a graph is much more pragmattic and maintainable, of course that varies with application.
Im reentering interviewing phase right now, and its funny revisiting these problems with a new lense. The mind is very plastic and its exciting, so far as things to come.
Total nerd out moment :v
Of course most people prefer to interview in a language which is less verbose than C++, which saves time.
Unless of course you have the infinity gauntlet
You also keep a "counted" and "visited" variable separately for no reason. There is no reason to visit a node and not count it, and you can't count a node you didn't visit. Whatever optimization you think you are getting surely isn't worth it.
As an experienced and good programmer candidate, the most important part of an interview is for you to evaluate the company. So the whiteboard is a great way to see if they understand what can be accomplished in 15 minutes on the whiteboard.
If they don't get it, you can end the interview short. Time saved today as well as the next several years working for a shite company.
I love the whiteboard interview.
I explicitly described the conditions of the original interview. The interviewer asked the candidate to "solve it" and it had to run. What part of that wasn't clear?
I also find it interesting that you countered with a completely different kind of whiteboard scenario. I agree that the scenario you describe is fine. I would enjoy those kinds of interviews all day and twice on Sunday. I'm not railing against an honest discussion with a potential employer. But that's not what happens most of the time, in my experience.
Also, the tone of your reply is that you reject the employer if they don't meet your definition of reasonable. That's great, but not everyone has that luxury.
Just give people a search bar and ask them to solve a problem outside their comfort zone. See what terms they use and how quickly they can arrive at a useful link. No pseudo-code or architectural diagrams needed. Just a link with a plausible solution. Because that's how most learning on the job actually happens.
Anecdotal: we had some problem to solve which required qua a lot of code to solve and only old sites with broken links came up in Google for the guy solving it so he decided to implement it himself. When I asked why that task was taking so long he showed me what he was implementing. The code he was writing had an implementation on an old site which had a broken link to the code; when I copied the name of the zip file that was linked in github; there was the code. It had no description or comments; someone just checked it in. It was not perfect code, but it shaved off a few days of writing it from scratch anyway.
I care about being able to code, which can be assessed from past code and a pair programming session and then efficient problem solving using your brain and internet. The latter is somehow less common.
So my favorite way now is; I ask them to 'solve' a problem they have never encountered and that cannot physically be done during the interview time (I am interviewing for software development and in our field you get asked for things that cannot be done in the time you are asked to do it all the time, so I need to see how you handle that); give them time to Google possible ways to do it and present a little plan. Then they need to pick, out of the plan, something they think they can do inside the interview time (see how confident they are and if they have any sense about low hanging fruit or estimations; I might suggest something else if the task they pick is only installing libraries for an hour ;) and we'll sit together behind a monitor and do it together. I'll usually tell them to stop after 15-30 minutes as I have seen enough at that time.
Additionally, just try to look up items on a language that is in (constant?) flux like Swift. Swift 1.x? 2.x? 3.x? 4.x? What's the API today -- naming convention changed, parameters changed, etc. All I can say is that thank goodness Google allows for date ranges with searches. :-)
White board coding interview are testing only one thing: how well candidate is prepared for it. And here what is wrong with it:
The assumption that candidate should spend his/her valuable time preparing for someone's assessment is arrogant. I do understand why Google and Facebook do it (the do other arrogant things), they assume you want to work for them so much you will study to make the cut. So, they track bunch of metrics, which makes THEIR life easier. They have baselines, calibrations, and other things you never have in the real life. Hilarious part is that they are both risk averse (better to not hire a good candidate than hire a bad one) and using brood-force approach (they will interview you endless number of time).
And if you are not prepared - you will most probably fail, unless you are really good at it or lucky. So, why should I prepare for Google's or someone's else interview? I have a interesting and very busy job, I just don't have time for this. I have commitments to my team to work on real products, not on fake problems from Cracking Google Coding Interview.
Just think how absurd it is?
So, starting from 6 month ago I:
1) Tell recruiters upfront I will not be spending a minute preparing for their interview process
2) I decline coding on the whiteboard. High level designs are fine, writing code - no, no exceptions
3) And the most important, I stopped asking candidates to code on the white board.
The most important skill of the software engineer is (IMO): ability to keep complex problems in context for long time (not 5 boxes and months), ability to manipulate them and ability to convince others that you idea is worth pursuing.
Because you want the job? Everyone is busy, that's a terrible excuse not to brush up on your interview skills.
By the tone of your post, my sense is that prior to your recent epiphany you weren't very kind to candidates who you interviewed.
>> Everyone is busy, that's a terrible excuse not to brush up on your interview skills.
I believe that their approach is arrogant, they just don't value candidates time.
I have a confession to make, I spent some time at Google. And after I left I was interviewing people using their approach and I regret it now.
When you interview for a company, you actually taking more risk that the company (talking about folks who are headhunted into interviews). If it doesn't work out, you will be out searching for a job, you career growth may be slowed down. And what is the company risk?
I'm definitely confused. You don't want to waste time preparing for an interview, but you will waste time interviewing at a company for a job you don't want?
Yes, there are lots of companies hiring. But in my experience, in preparing for one software interview, you're preparing for others as well.
I interviewed at Dropbox, Amazon, Valve, and Indeed, within a span of a few weeks, and the prep work (Cracking the Coding Interview) was applicable to all.
That's different than asking "Why should I prepare for a job?"
If you want the job, you'll put in the effort to prepare, regardless of your feelings on the process. That sacrifice (2 hours a day for a month) is minor in the grand scheme of things. Granted to the OP's point, Google probably isn't worth it. But that's a value decision each candidate has to make for themselves.
I'm preparing for my brown belt in Krav Maga. The test is 6 1/2 hour grueling physical exam that includes a comprehensive test of all the material from the previous 4 belts. Not only that, we're the first group eligible to test, so the instructor wants to set the standard with us.
Not everyone wants to put themselves through that hell. But those that do will put in the effort to be ready come test time.
Plus, if some one has to 'prepare' for an interview that is supposed to test people's capabilities to do 'everyday' jobs, then you are hiring the wrongest possible people out there.
It's about the thought process when breaking down a problem and the ability to organize and communicate their thoughts. It's also about exploring a problem space. How carefully does an engineer consider edge cases? What kinds of things are important to them?
A whiteboard to me is a much simpler and accessible medium through which to explore a problem vs setting up an environment and having to type code and dealing with all the minutiae that comes with actual development.
Of course, it isn't the ultimate method of evaluating a candidate but it's certainly valuable.
Isn't that a more realistic scenario? How often do you give an (employed) engineer a task then ask them to immediately explain what they'll do to implement it?
If, however, the job requires careful consideration of dependencies, time domain, and, yes, edge cases - then you are NOT testing for that.
Lock the candidate in a room and give a few hours to let her to produce the result would be a better measurement.
Lots of interviewers suck. That isn't a property of whiteboard interviews.
I won't say this is you, but it's funny the number of people who will interview and say something like this and then still give a non-trivial problem/question to whiteboard.
Reminds me of a guy who interviewed me several months ago at a place in Mountain View (not Google, but another).
He started by asking me to create an object with a couple attributes. Then he slowly began to add to the problem by asking for X, then Y, then Z.
Little by little, the code became more complex because he wanted iteration, etc.
He would say "I just want to know that you're able to code."
Later on, I found out he didn't like what I wrote, meanwhile all the basic elements of coding he wanted I was able to add without any problems and I met his specs.
If there's a "communication issue" in whiteboarding, perhaps the interviewees shouldn't shoulder all of the blame. Perhaps the interviewers need to temper their expectations and learn to communicate them better, because obviously there is some disconnect in a situation like this, and it's not the first time I've seen this before.
I've been doing this for 15+ years professionally, have a master's in CS and I struggled to answer many questions. Just stood there blinking like a goldfish.
If companies really wanted to simulate programming work, you'd give me 10-30 minutes to Google the problem because THAT'S HOW IT WORKS IN REAL LIFE. Which is how it should be; rarely are you solving a new problem, usually other people have faced it before, it's probably far more efficient to start with a known working solution and iterate from there.
Look, of course there things you should know. Data structures, algorithm basics, some complexity theory, etc. But asking me to output numbers in a matrix in a spiral fashion does not translate into real-world ability.
I find the more important developer skills are people skills and project management skills. How well do you work with others? How do you resolve conflicts? What's your methodology for grouping work-- Jira tickets, sprints, etc?
But almost none of the interviewers seemed to care. They wanted to know what exotic technology skills I had, not that I could work with project managers and marketers effectively.
Take-home projects are more time-consuming but the least unfair, whereas whiteboard coding is the shortest but most unfair.
I blame Google for this curse. I hope the next time I go looking for a job this process has changed.
Ask me about past projects. Want GitHub examples? Fine. But whiteboard coding some non-real-world problem?
I get that companies need some sort of filter, but whiteboard coding is not the answer, IMHO.
I've worked with folks with 15+ years that could technically code but they took eons to deliver and their solutions were unmaintainable. Some of them with advanced degrees too.
Small sample size, but the few folks I'm thinking of were such bad hires that could have been avoided if we had them write some code or put the proper emphasis on the coding exercise we had them do.
All small programs are maintainable, no interview process will tell you if a developer can deliver large, complex programs that are clean, modularized and easy to maintain because there's no time to do something of the requisite size.
It's true there are experienced devs who suck, but that doesn't mean whiteboard coding is the process that filters them out.
Have someone else pick a coding problem (that you as the interviewer don't know beforehand), and work on it from scratch together with the candidate.
Being upfront with the candidate that you don't know the answer yourself puts the candidate at ease, and you'll be able to better judge the candidate's soft skills (communication, critical thinking, empathy in case I don't understand the problem).
Most of the problem seems to me fundamentally unaddressable without verifiable portfolios, but those have their own problems. Even in industries where portfolios are standard, plagiarism is a thing - how do you get the verifiable part? I want to hire someone great, not just someone who was on the same team as someone great.
I'm also frustrated with how people have developed disdain for anything whiteboarding. Asking leetcode puzzles in interviews is bad. Asking questions from CTCI is worse and amateurish. But... asking to whiteboard a problem that you had to solve on your own job in limited time is good! Interviewing is hard because crafting such questions in a way that it abstracts away minutia of transient technologies but retains essential problem solving is hard. This is exactly why, a right policy for a company is to establish being an interviewer as a privilege that needs to be earned because not even all brilliant programmers are good at it and interviewers must take time to craft good question and show care. When they don't, they turn to leetcode, pick random question and give whiteboarding a bad name.
And no, whiteboarding is not bad. What is bad is asking to do X using MongoDB and RectJS because technologies like that are transient. Specific technical tasks that employees might perform in a given point in time are transient. Ultimately what matters is ability to learn, process and use that to solve a given problem. Ofcourse, unless you are company who does nothing but data driven web forms. In that case, yes, go ahead and ask candidate to do just that.
As the article mentions though, the term is a bit vague and is overly broad; for example if you're doing a system design question, I'd argue that the whiteboard is the best choice for an interview, since that's how you're most likely to collaboratively sketch the design of a system in the real world.
I think the problem can be restated at a more general level; does the interview test the sort of skills that the job requires? Most people here are correctly pointing out that the skill/knowledge required to write out pseudocode for quicksort is almost entirely uncorrelated to the skills involved in most software jobs.
The only time I've used whiteboards in my job is either when I need to hash out a solution or approach with my coworkers, because I'm confused or don't understand the problem, or when I need to understand high-level architecture for a system. It's a tool for clearing one's thoughts and for getting a team "on the same page".
If you're hiring someone to code-monkey a bunch of JIRA bugs, then whiteboarding might not be a relevant test for them. If you are hiring someone to build out new features efficiently or redesign architecture, then whiteboarding may be useful for having them describe at a high-level how they would solve problems. In both cases, writing syntactically flawless solutions on a whiteboard is a waste of time for both the interviewer and interviewee.
I say this as someone who worked at one and interviewed at others. You really do need to treat it like an exam.
That general premise is right, we've lumped too much into the term "whiteboarding", and it's worth unpacking into the different interviewing practices we may like or dislike. Some things people don't like have nothing to do with an actual whiteboard (e.g. testing esoteric CS knowledge or deliberately creating a stressful environments), and some things that involve a whiteboard IMO are ok (e.g. sketching out a system diagram).
That is STILL a thing (judging by HN) and it's useless. I don't think anyone would ever think it's a bad idea to have a whiteboard on hand if a candidate is asked to describe how they would design some nontrivial system. Being asked to describe something without a whiteboard in that case, is even harder.
The objection you often get for the latter kind is that it tends to benefit the extroverted kind that likes to babble and sketch, whereas a candidate who would prefer ten minutes alone with a pen and paper might not do so well. I think are some merits to that complaint, but I also know from experience that being able to babble and sketch is really important.
Making engineers write code on whiteboard is just comical. If we weren't so used to it, we'd probably have laughed at the idea. In 2018, any company still using whiteboards to write anything more than pseudocode is just playing it too safe or being really lazy in changing their process. Just give them a laptop and have them use coderpad/skype interviews or any of the plethora of collaborative code editors out there. Or even, dare I say, an IDE. You can still have the whiteboard in the room to discuss the idea. But write the code on a laptop with internet access.
That hasn't stopped it from showing up in every programming interview I've ever done.
Well, yeah, other than tail recursion with tail call optimization, stack consumption, if not stack overflow, is always an issue.
> and honestly many recursive algorithms are quite hard to parse in your head especially once you add some edge cases and some other entropy.
I find lot of things are easier to conceptualize recursively than iteratively, though parsing really depends a lot of the language.
A question I've had in an interview was what is the difference between recursion and iteration. Fairly easy to explain, including examples of usage.