The reason they are important is that they are part of every engineers day-to-day work. We use them to collaborate and design and understand.
Therefore, if a candidate can't whiteboard a design, solution, architecture, etc. in a manner that other engineers can understand it, they are going to struggle.
That being said, the way Google and other companies use whiteboards is an epic fail. Asking someone to code on a whiteboard is stupid. Asking them to solve algorithm puzzlers on a whiteboard is lame. This isn't how we use whiteboards every day so why should a candidate be expected to use them this way during an interview.
The employer (or school, etc) wants to make successful hires and to avoid bad ones. False positives are always a big problem. False negatives are usually much smaller one. A process is good if it produces good hires, and no bad ones.
In principle, a process that hires 3 good candidates from a pool containing 5 good candidates and lots of bad ones is good. Avoiding bad hires is paramount. Missing 2 good hires is not as bad as making one bad hire, not near as bad usually.
Most employers don't care about false negatives at all. If they do, they probably care most about missing really good outlier hires, not mistakenly selecting the 5th best candidate instead of the 4th. The only reason to care is fairness. People instintively care about fairness so this affects practices but it's not nearly like false positives.
Employers that need huge volume (eg, the army) are the only ones that care about false positives as much as candidates do.
The candidate (student etc.) generally feels the process is "broken" when it is unfair to them. Unfair means that a person could have done the job well, but cannot get hired. Ie, if the candidate is a "false negative" then the process is broken.
Anyway... When things become systemic, the "brokenness" becomes acute to a candidate. If whiteboards (your architecture version, Google's CS version or any other version) are prevelant and you suck at them... you can't get hired. There are people who suck at your test (whatever it is) but would be good at the job. Your proxy is a biased against some people, every proxy is.
Like I said, a lot of things are like this. One side is working the numbers game, the other side isn't. Insurance markets, college entrance, executive appointments, PayPal's fraudster detection (bastards!), credit scores, investment (even startup investment)...
The problem is that very few companies know how much false negatives are costing them, so it is very difficult to evaluate whether the false negatives are—cough—a negligible tradeoff against weeding out the false positives.
False positives are right in your face. But it is nearly impossible to systematically keep track of the candidates that aren't hired to see if they are successful elsewhere.
So people lean towards eliminating false positives at all costs. It's another variation on "Looking for the watch where the light is better."
I would agree with you if the supply and demand weren't so skewed towards top developers. Do you think you are choosing between A and D people, or are you really choosing between C and D people and A and B people never walk through the door?
People complain whiteboarding because they've had bad multiple bad experiences with hiring processes that involve whiteboarding and they came to a conclusion that whiteboarding itself is the problem.
Unfortunately, you can't fix a bad hiring process by simply changing the technique. Each technique has its own pros and cons, but no technique will guarantee success.
These are the most common problems I've seen with hiring processes:
1) The people doing the hiring don't really know what they're looking for. Instead, they go by a vague, handwavy notion of whether the candidate is "a fit" or not. You have to define what "a fit" means in such terms that all of the people involve understand it, agree on it and know how to test for it.
2) The people doing the hiring don't know how to test for their criteria. Whether you're using whiteboard or a take-home project or some other testing technique, you have to design the test so that it helps you observe the traits you're looking for. [1] And you have to actually train your people to interview candidates.
3) Lack of transparency. This is a huge problem and it infests all aspects of hiring. Some recruiters won't even tell you which company they're hiring for. A lot of companies misrepresent what you would be doing for them, sometimes intentionally, but usually not. Some companies won't give you perfectly reasonable information about the job. [2] And, thanks to the litigious nature of our society, no company -- anywhere, ever -- will give the candidate honest, detailed feedback of why they were rejected.
4) The company is unreasonably demanding when it comes to candidate's personal time. The typical two-stage process -- a phone screen followed by on-site interview round -- is demanding enough, because it involves more than just the interviews. The candidate has to spend time and effort on other aspects, too: multiple phone calls with the recruiter, preparation for the interviews, travel, and juggling all of this with their personal and professional lives. Some companies don't understand this, so they think there's nothing wrong with a process that involves a take-home project, a debriefing phone call, a face-to-face conversation to test for cultural fit and a full-day on-site interview round.
Most companies don't even know that their hiring process sucks. Of those who eventually realize something is wrong, many end up cargo-culting whatever they read or heard about "more successful" cases. As things are right now, the whole situation is eerily reminiscent of the fuss and hype the industry went through with software development processes. I wouldn't be surprised to see yet another wave of parasitic consultants pop up to prey on companies by flogging their hiring process improvements and best practices.
----------
[1] This is where a lot of people's complaints go wrong. The most frequent grumble is: why does this company's interview process focus on algorithms and data structures, if you'll just end up coding some services in Java? If the company is doing things right, they're using these topics as a tool to observe and measure whatever it is they're looking for; most often, it's the candidate's understanding of computational complexity. Just because you won't be writing your own implementations of common data structures and algorithms, it doesn't mean you shouldn't know how to pick the one that won't blow up your memory or execution time.
[2] I had a case where I was interviewing with a company that gave me a print-out overview of their benefits, which included the price of each health plan, but not what it covered; when I inquired about it, they replied they wouldn't be able to give me that information until I signed the New Hire NDA.
I've started to turn this around and so far our senior candidates have loved the experience. (I only wish I had come up with the idea.)
Instead of asking to write code on a whiteboard and solve an arbitrary problem, couple of our engineers came up with an inverted problem. And ever since seeing it in practice, I've been trying to introduce it to every interview I can think of.
We write a piece of code on the whiteboard, and then ask the candidate to review it, as well as modify it to better suit the problem and context. This way the question turns into a discussion on design, constraint exploration, service expectations and externalities. Hell, sometimes it even goes into deep language design issues. Sure enough, it still measures a level coding skills but puts a much higher emphasis on understanding what the problem and its scope really is.
It's also a lot of fun.
I work at Google, opinions are my own.
I think your assumption that Google interviews based on what you will do on the job is wrong. The reality is that for most SWE positions, we can't assume you will know the things you'd be using for the job because of all the internal tools. Thus, algorithm interviews are more or less a proxy for some combination of general intelligence and coding questions.
I'm not saying it's perfect and there are many things I don't like about it, but I think it's important to know what the goals are when making a critique of whether the process meets those goals.
It's a proxy for one particular style of coding questions: leetcode. It's nothing more, nothing less.
Calling it a proxy for general intelligence or coding in general is a joke. That's propaganda passed around the company to convince people that the practice should be continued. It strokes the employees own egos to think they passed some magic intelligence test so it motivates them to keep repeating that it measures intelligence/skill.
IMO the biggest problem is that small startups copy the Google's approach while their hiring environment is completely different.
As an aside, if you've never done systems design or pseudocode on a Smartboard, you're really missing out. Copy/paste, duplicating a slide, recalling earlier slides, etc. Man, that's the way to design a system with quick iteration but still no worry of losing your work.
Some of the biggest productivity gains I've had over the years were related switching from "writing code down" to "thinking in code" mentality and abandoning linear, paper-like ways of thinking, which hindered me when I was in college.
For anyone who believes that paper and whiteboards are "good enough" for coding, I highly recommend watching some of Victor Bret's or Alan Kay's talks. Pretty much any of them. They consistently touch on the subject of dynamic media as a way to empower people to... well, think better for the lack of better terms.
Hey if they work for you, that's great.
But the simple fact is that they don't fit everyone's brain. And that there are other tools available to accomplish precisely the same ends -- some of which have many advantages over whiteboards, in fact. Like these things known as "pen" and "paper", for example.
So this idea that they're part of "every engineer's" day-to-day work is, quite simply, disconnected from reality.
I do agree with you, however, that the problem lies not in the whiteboards themselves but in the way they've used. Which has truly been an epic fail.
> Like these things known as "pen" and "paper", for example.
When you need to share this pen and paper, you use a whiteboard. I don't understand this hate for whiteboards, which are a cross-industry cross-profession standard (including medical) when collaborating.
One of the more interesting things I have noticed is that happy engineers have a little free time each day. They aren't under crushing pressure at all times. To this end, it's very common for whiteboards to accumulate drawings and doodles. This is often turned into "the elaboration game" where one doodle is built upon (by a little or a lot) every now and then. This is probably because coding is problem solving, but also because it's a creative endeavor. Engineers who are happy tend to work around other happy engineers and those engineers are all creative with free time.
If that's the kind of whiteboarding you do, no problem. But, don't ask me to write a merge sort in C# (been there done that). If you ask me to sort a list in C#, I'm going to write:
sortedList = employeeList.OrderBy(e => e.LastName + " " + e.FirstName).ToList();
I get so hung up on this it’s changed how I ask the question. The last time I asked a sort question, all I wanted was a compound comparator. And even then I couched it as “we want the rest endpoint to support sort criteria so we can do a top five list, but to sell the idea, we are going to sort in the UI for now. Give me some code to do that.”
Every candidate I interview has the choice between coding on a whiteboarding, and coding in a text editor with rudimentary code formatting.
I really like it when people code in the text editor, because that's one less thing I have to transcribe in my interview evaluation.
Regardless of whether they will choose the whiteboard or the laptop, I have never, and will never mark people down for typos, confusing .length with .size, a missed semicolon, or any other petty bullshit that isn't pertinent to the problem. I'm not hiring a compiler.
AFAICT, the backlash is around interviews where candidates are asked to write code (or pseudocode) on a whiteboard. Being able to implement bubble sort on a whiteboard does not correlate very well with being able to deliver business value, in my experience.
I spent about 30 seconds looking at it, but at least the first chapter 1 seems to be about proper whiteboard techniques
Basically, if it is an idea, concept or design, draw it out. If it is functionally correct code that compiles, screen-cast and type it out.
The time before that was for a database migration where I mapped out each step that had to be done and in which order.
The point is not to have or not have the whiteboard during interview but how and what it is being used for.
The best way I found to interview candidates is to have few different discussions. One of the discussions I like to have is to try and solve some kind of problem that you could potentially have in real life. I am solving problems with people this way on a daily basis so this lets me observe candidate in a setting that is already familiar to me and hopefully to the candidate. The whiteboard is then used exactly as in real life -- as an tool to visualize and communicate ideas and hold it as a kind of cache and reminder for the duration of the discussion. The whiteboard is there during interview but I will not require candidate to use it. If I have trouble understanding the idea I may ask "ok, I can't visualize this, could you maybe draw it for me?"
Nobody programs on whiteboard in real life. If I need to program for presentation, for example to train my team on some topic, I will bring laptop.
The key about whiteboarding is it take away all the specific syntax and gets to the heart of the understanding the logic.
Thats what collaberation is for, i think many young engineers that only code with an ide are nervious whrn they dont have autocomplete available and they lose focus on the core logic.
Programmerd used to write on paper ... this entire process (coding without the ide/search engine) is lost.
But this is the part where the programmer shoes their strength in logic ... not syntax memory.
I feel like there's two angles to this; 1. understanding complex algorithms commonly used as tests. 2. understanding how to convey information on whiteboards efficiently, common paradigms, etc.
#2 is what I think I'd actually enjoy improving. #1 is just SAT style stuff that I infrequently use in my day job and serves as an annoyance more than anything.
I think this is largely the point.
They are terrible at compiling and syntax checking.
Theoretically you should already know whether someone can do the physical code part. That problem is largely solved for and don't require in-house interview.
In-house interview should be used for c̶o̶n̶f̶i̶r̶m̶a̶t̶i̶o̶n̶ b̶i̶a̶s̶ ̶f̶o̶r̶ a̶g̶e̶/̶r̶a̶c̶e̶/̶g̶e̶n̶d̶e̶r̶ determining if the candidate can think/design/solve for the domain space they're being hired into. A whiteboard is a really good tool for assisting in that.
They are optimizing completely different metrics than you do. They want crème de la crème developers that are perfectly trained not to think about certain classes of problems and waste time there but instantly come with acceptable answers, immediately recognizing the structure of the problem and having the ability to faultlessly transform it into a piece of code without a debugger. It allows the training from the best universities to shine.
The problem is when everybody starts doing the same, but without the prestige, salary, equity and lifestyle that Google provides.
Or without actually needing to problems that even remotely resemble the kinds of problems that Google (sometimes) solves.
I feel slowed down having to write out on a whiteboard when I could instead write some dummy code to get a point across. It just seems crazy to assume all developers everywhere must be good at white boarding.
I tend to move my hand faster than I can hand write, which is why I like typing for all forms of explanation.
Especially since I’m on a full remote team, whiteboarding would be really weird.
I'm sure a shared digital sketchpad would accomplish the same thing for remote workers.
What a cluster it's all becoming on the software engineering side.
And I need to know what the work exactly entails, and what is expected of me. Many interview questions are disjoint with what the job actually requires.
>Prove to me you can
I can show you my past experience, and I can do technical exercises. What I can't do is devote a ridiculous amount of time and effort to poor questions.
As someone who has hired a lot of devs over the years (almost exclusively for our offshore team in India, but sometimes in the EU), I can tell you that the number of candidates who embellish and down right lie about their capabilities and past experience is shocking.
Truth is, I hate both sides of the interview divide, as interviewer and interviewee - it's a horrible, inefficient, flawed process regardless which side you're on, and nobody has the answers.
Wow, what an incredibly tone deaf response.
>Some companies simply do not understand how to properly engage in employee selection.
Maybe changing this prospective is the point of the "incessant whining."
>I need to know you can do the work, prove to me you can, I will then hire you and pay you to work.
I'd have to know how you are testing, but I'd bet dollars to doughnuts your method has no way of predicting output in any meaningful way.
>What a cluster it's all becoming on the software engineering side.
Absolutely. I would say it's endangering the overall quality of the industry. The saying goes, if you are a bad manager or a bad company the first people to leave are the A and B players. The people that will never leave are the C and D players. I suspect people who do all this trivia don't even know what an A or B player looks like.
It's really not though. Here's the bottom line: You want money from a company. The company doesn't owe you jack. shit. If they fucking whiteboard, and you want money from them, then do the whiteboard. Later, when you are employed by them, try to suggest they improve their process. If you have better options, take them.
> Maybe changing this prospective is the point of the "incessant whining."
Sure. But is that the companies #1 priority, or do they have other things to do, like make money and stay in business that take precedent? Anyways, the way you do this is from within or providing feedback and having conversations with recruiters -- you know, human interaction. This job board is the ultimate culmination of millennial passive-aggressive behavior.
> prove to me you can (do the work)
A take home exercise only proves they can get the work done elsewhere. It doesn't prove that they actually did it.
I like the format, but it obviously has other downsides, such as a higher up-front investment from the candidate.
That being said I found the format enjoyable last time I went through it. It was less stressful during the interview itself, and I felt more confident walking in. I would recommend it to companies who are considering it.
We use a whiteboard in our interviews for sketching UI, and sometimes drawing a database table. Generally candidates find this much easier than talking through their design, and we think that interview very closely represents what we do on a day to day basis.
If you're asking candidates to balance a binary search tree when no one in the history of your company has ever had to do that, you're asking the wrong questions.
We do a mock technical meeting with multiple members of our tech team and the candidate presenting options, talking through pros and cons, etc. Much of the interview is about assessing communication rather than technical skills.
The interview is basically a standard tech meeting that we hold regularly in the team to discuss designs of new projects.
In my opinion it is all about aligning your questions with the day to day task you expect from people. If the work is very algorithm heavy, by all means probe for that in the interview.
I base my interviews around one main question: assume the tech challenge you written beforehand is a prototype for a complete product/service. what are the steps necessary to get us there and beyond?
I do not care about the candidates tech preferences or the exact solution as long as the argument for it is coherent and not just based on heresay. Then I probe for a couple of things within their solution where I see potential weaknesses based on their argument, experience or code in relation what we look for. It is more about problem solving, decision making and communication than computer science.
Candidates are free to just talk trought it or use whiteboard/paper to draw it out. But if you choose the former you better not forgett what you said five minutes ago.
Obscure “I had to google it before asking you” problems are the problem not the whiteboard. I think whiteboards are good visual aides.
Sometimes I just ask people to draw a frog though.
I don't have any solutions only complaints and bitterness, sorry.
We only do them when we are pretty excited about a candidate but need more information to make a hiring decision.
It's cheap, really, considering the cost of sourcing candidates and the cost of making a bad hiring decision.
Why would I go through that trouble? I have 20+ years of experience that I can explain how I architected and developed from the website, to the middle tier, to the database to multiple VPCs on AWS and dev ops. I'm not going to do homework.
When I was first starting out I might, but living in a major metro area that's not on the west coast, there are more openings for senior devs/architects than people to fill them.
If a company wants to try me out, I'm more than willing to do a contract to perm, but my hourly rate is going to be enough to cover self employment taxes, make up for not getting paid for time off and at least two or three weeks between employment.
It still seems strange to me to pay for throwaway work but I can also see how that’s really just my personal sentiment / bias and this is probably a pretty good and balanced approach.
I said no thanks and moved on to other companies. Felt good. I just avoided working in a culture where there will be high pressure to always perform. :)
They can afford it, but still, it's far to say that the wasted effort isn't entirely one-sided. Hiring is an expensive and inefficient transaction.
Figuring out how to make this both more fair and more efficient is a really tough problem.
Asking someone to solve an obscure mathematical problem (the Two Egg problem seems to be in fashion) doesn't do much except test whether the candidate has memorized the answer.
When not in an an interview I like playing with these kinds of problems, but if I look it up I'll probably find interview prep where it shows the answer as well.
Could you summarize just the problem please?
If an egg breaks when dropped from floor n, then it would also have broken from any floor above that. If an egg survives a fall, then it will survive any fall shorter than that.
The question is: What strategy should you adopt to minimize the number egg drops it takes to find the solution?. (And what is the worst case for the number of drops it will take?)"
Is there any scientific evidence to support that, or is that just industry hokum?
And communism probably redistributes wealth if it is administered correctly.
If companies want to hire based on general intelligence (not personality, team work, communication and so on) then they should administer IQ tests, which are based on a century of rigorous research. That would at least give you a fighting chance of measuring G.
Why do you think white boarding can measure general intelligence?
Question: How do you validate that the posted company or job position doesn't need whiteboard? Is it after the fact, as in a disgruntled candidate complaining? I couldn't find any information about this on the site.
Yet a lot of people are never really taught to do it. Perhaps they pick up this fundamental skill just fine after a couple whiteboarding sessions in the company.
If a company is rejecting candidates for not having a skill that is really easy and quick to obtain, they'd better not be one of these companies that keep complaining about shortage of talent.
Yeah, this one is pretty bad. But let’s try to do better, not worse.
I don't agree with making candidates write algorithms they don't need to know in a format that they don't need to be able to write them, but I am in favour of testing candidates thoroughly.
Anyway, I hoped you could search only for jobs where this box was checked by the company, but apparently not...
EDIT: It does allow searching for minimal salary and remote jobs, among the wishes listed in a sibling comment.
EDIT: Ok, my mistake, my memory is failing me. "Doors that close" is used in a whole bunch of Joel blog posts, and "walls and doors" is used in the original Joel Test description.
But WaybackMachine seems to confirm that the official label from the "Joel Test" has always been "quiet working conditions" and does not appear to have been changed.
Even better, I would love a site that classifies job offers/companies by:
- Has an onboarding process for new hires
- Has quiet working conditions / open office
- Has clear requirements
- Salary range
- Allows remote working
- Type of interview and time to get a responseUnfortunately we haven't yet expanded much out of the Midwest, so it MAY not be of use to you yet. But check it if your interested.
I went there, typed in "developer" in the search box, and got dropped on a map zoomed in on the Kansas/Oklahoma border and a message saying my search didn't match anything. Took me a while to notice the "zoom out on the map" part. Not sure why I landed in the middle of nowhere in the US, I'm located in Europe. In any case, super unintuitive.
Also, this might be an American thing I'm missing, but which (if any) option of "Pod Office Layout" or "Closed (Cubicle) Office Layout" corresponds to "proper walls and a proper door"?
I'd also suggest adding a filter for minimum salary.
Hope this helps.
I understand that the company needs a way to vet people to make sure they are technically proficient for the job. However, there must be a better way of filtering people. I just bailed on a company after they told me what the interview process would be:
- Take home coding quiz where you need to sign up and use their algorithm platform. As you would expect, there was asynchronous programming and a recursion algorithm involved (two for one!)
- 3 more technical interviews. 2 of which were screen share and/or white boarding sessions. 1 is a "riddle part", which I assume is some kind of brain teaser involving a recursive algorithm.
After I saw the coding quiz and all the follow on stuff I just told them I wasn't interested. I was kind of offended, and it didn't put me in a positive mindset towards the company and engineers that worked there.
Hazing.
It's just monkeys making sure they only hire other similar-looking and similarly-acting monkeys.
I'm just looking for the candidate's thought process and some pseudocode. I could do the same thing in an empty text file but the substance of the interview wouldn't change.
My feeling right now is that being anti whiteboard is focusing on trivialities like complaining that the office style guide uses Allman vs K&R bracketing or something. But I'm open to having my mind changed if there's something more to it.
Most problems in practice that require non-trivial application of algorithms, dynamic programming and the like have two characteristics that make them differ considerably from whiteboard style quizzes. For one, they're going to be much less contrived (pick a random leetcode question for an example of this, odds are it's contrived). Secondly, they're going to be resolved when developers talk to each other about them and there is recognition of the solution, which most of the time is an application of algorithms and data structures with library implementations.
The ability to whiteboard things like "given an array of integers and a target find the indices of the pair of integers in the array that sum to the target" and "find the first missing positive integer in an unsorted array in O(n) time and O(1) space" provides almost no useful information about a candidate's ability to solve an actual problem the company faces in most instances. There are exceptions, but interviewing everyone for the standard of that one exception is asinine.
Actually hand-writing code with a pen has always seemed weird to me. As a programmer, I compose code with a keyboard. So I give candidates a laptop and use an interactive screensharing tool (I like https://codepad.remoteinterview.io) where they can run code in the language of their choice in a browser, and I can watch and talk through the process.
I've done a lot of interviews over the years, and I've encountered a couple stereotypes:
1. The gotcha interviewers. He pulled out his old algorithm text book and found the hardest problem.
2. The no bullshit interviewer. Asks you to code a somewhat challenging, but solvable problem. No tricks. Basically non-trival fizz buzz problems. The problem with these is there are only so many practical problems you can give before it gets put up on leetcode, and every interviewee has memorized the code.
3. The clueless interviewer. They try to give you a weird mix of an IQ test and a personality test, and maybe throw in a little bit of API trivia while they are at it.
My preferred way of testing people was usually to try to get them to show me that they have thought about why they develop software in the fashion that they do. I would prefer to do this in person, at a very high level, but it often ended up being a written test (where necessary, the language was your choice, or pseudocode). Is this wrong?
This is the problem. There was recently a large HN thread about the take-home projects and how so many people didn't like them.
None of the options are popular: if you use whiteboarding, people will complain it's a bunch of brain teasers unrelated to real programming work. If you use take-home projects, people will complain about doing unpaid work.
Would professional certifications help? I doubt it -- they would need to be based on standardized tests, which would have the same drawbacks as the whiteboarding questions nobody likes.
The idea was to give questions which are almost a polar opposite of the strange trivia style questions you see in certification exams. Instead of the candidate having to remember which overload of an API returns a byte[], we'd instead talk about things like how they prefer to structure a project, and how this feeds into maintainability, etc. If the person was into object orientation, we'd talk about that, if they were into a more functional style, same angle, but I want them to have thought about it from a software engineering side. It sounds wishy-washy, but with just a few pointed questions, you can detect both BS answers, as well as someone who hasn't really thought about it. I tend to find that this quality in an individual is a very important predictor of performance, as it indicates deep care and interest about their craft. With good candidates, you can get really deep into a discussion and know within 5 minutes that they are quality.
Along the way, you'd also get a pretty good picture of the persons strengths and stylistic preferences, which you can use to determine how and where they would fit in with the team(s) you had in mind.
The only downsides are that I wasn't always available for these interviews, and the written equivalent intimidating and could take long. Also, various people swore that they either can't perform well in written or verbal conditions, so perhaps letting the candidate choose between the two might be beneficial.
Yes. If you have problems with anxiety or imposter syndrome its a special kind of hell - especially when you go in absolutely able to do the work and being qualified, and then getting a hard no on the basis of "you're not a good enough programmer". Even for someone without an ego to be harmed, it feels like a cruel and arbitrary way to determine your future financial and societal well being.
That said, I don't think whiteboard programming is always bad but it is a skill that I don't exercise and it showed.
My advice, talk through the problem with the interviewer and don't start writing code on the whiteboard until the interviewer has ok'd your proposed solution.
I was the same but I do a lot better now after having done some 200+ technical interviews and a lot of practice on my own.
I can fully understand dislike for puzzles and being asked to implement irrelevant algorithms in pseudo code. The interview should reflect the job being interviewed for.
I've found whiteboarding to be mutually helpful in questions about system architecture. Plus, it's something that we actually do on-the-job.
I mean ask yourself this: do you ever use the whiteboard to write code to the extent you expect some poor kid trying to get his first job to do? Hell no, you screen share an IDE or paste code in an email.
People used to have to write code on paper (I did this a few times in college ages ago) and that comes from the cost of compiling stuff way back when. Computing time is friggin cheap, that's why no one does it. To expect some new guy to be adept at that ancient practice is silly.
[1]: https://en.wikipedia.org/wiki/Encoding_specificity_principle
I think few frontend developers would consider the work they do to be "UI design".
As long as we keep asking people to do things that aren't like the work that we do, we will continue to get mismatches and people that interview well but work poorly. I don't have a great solution, finding good people is hard.
- When working in front of a computer, people get worse at communicating. Even if they try to speak out their thougts, it usually doesn't work well, as thinking and operating an IDE (or whatever at hand) already occupies a lot of brain capacity.
- Take-home exercises are hard to control: You don't know how long a candidate worked on it. Even if there's a target like 4 hours, some might work all night on it - either because they couldn't do it in the allocated time, or because they fear some disadvantage. Apart of that, they might pay someone to solve it for them.
I always fail whiteboard interviews. I can't code at all on a whiteboard.
...and probably a better software developer than 99% of the people they end up hiring.
Some companies look at your GitHub profile instead, which imo is much more unfair, because it presumes you've had the free time and the desire to work on side projects, which shouldn't be a requirement for a job.
Maybe companies should adopt an either-or policy? Give the interviewer the option to demonstrate their skills in the form that works best for them.
Maybe I’m missing the point though.
I usually (ok, almost always) flesh out designs and pseudocode with pencil and paper anyway, so changing to use a whiteboard isn't an issue.
Standing in front of a handful of strangers glaring at me while I try and figure out some stupid algorithm they had to Google themselves is hazing and should be stopped.
Edit: Also, dinging me for small syntax issues on a whiteboard when I'm used to using an IDE is not really cool.
1) https://whiteboardfree.com/job_posts/52 - Lyft - Data Engineering
2) https://eng.lyft.com/interviewing-tips-for-android-engineers... - "Expect a few coding questions either on a whiteboard " ( Dec 21, 2017 )
Pretty sure Netflix (also has a job listed) does whiteboard based evaluation too.
I don't use whiteboards for coding tests, I use whiteboards as one (of several) ways to evaluate how someone thinks on their feet without having Stack Overflow & Google at their fingertips. I don't only want to know if someone can code, I want to know about their process, how they think about things, what assumptions they start with, and what kinds of things they like to explore. I want to see some personality. Take home problems don't measure that very well, nor do coding tests with online resources available.
I've never met a perfect interview, but what are some suggestions for more acceptable and/or better ways to evaluate how someone thinks on their feet?
I remember hearing that Google's done quite a bit of research on hiring practices vs outcomes, and that one of the leading predictors is having external groups do the interviewing, i.e., making sure the people doing the interviewing have no stake in the outcome.
Interviewer to engage in conversation with applicant about applicant's prior work in detail. If the applicant can give sufficient explanations of systems/projects and the interviewer can ask appropriate probing questions and get sufficient responses to those questions from the applicant.. then the interview can be concluded positively.
The crux of it, from the applicant point of view, is that they want to be believed and treated "professionally". Further it's "insulting" to be questioned about anything other than specific experiences. That's why you see objections to every sort of "objective" line of interview:
sample projects - too much time, why am I coding for you for free?
github/open source - I have hobbies outside of programming
white boarding/google doc coding - not my environment for writing code. I need emacs with xyz keybindings or we're not going to make progress.
algorithm problems solving - the job doesn't entail re-implementing hash tables, or sorting algorithms... The question(s) are not germane to the position
etc etc etc
Yeah, I agree; I have the same hypothesis that this is what people want. And it's a problem to assume and/or act like talking about anything other than specific coding experience is in any way insulting. That's not exactly a realistic expectation, nor is it a great attitude for getting hired.
Personality, behavior, poise, attitude and communication skills are absolutely relevant to someone's ability to do their job on a team. If you can't think on your feet or answer a question without a computer in front of you, and you start getting angry, how will you behave in meetings? That behavior is precisely one of things I look for when I ask candidates to think on their feet.
If someone assumes that being asked certain questions is "unprofessional", then that's a red flag and I'll be more careful before hiring someone like that. Now that I think about it, there's a bit of irony that if someone performs poorly on these kinds of questions, I'm likely to spend more time investigating that and asking more questions along those lines.
Heh, I code pretty often on paper when I'm working through a design and my style has evolved to just using < and > as proxies for curly braces which saves me time, since trying to draw a nice curly brace takes me so long.
I cannot interview a company if I am doing a take home assignment. With whiteboarding, I get to also assess my potential co-workers abilities by seeing if they are asking interesting questions.
Usually this means drawing stuff on the whiteboard with boxes and arrows. Not looking for the perfect system or 'correct' solution, just really having a look at what the candidate is experienced in and how they think.
Whiteboards are fine for that use case, and can be very expressive.
Doing binary search trees and stuff though doesn't seem as useful really.
There's no interview process that works best for every candidate; some prefer whiteboards or homework or practical debugging on their on computer or hand-wavey design or whatever. Candidates (and companies!) could save a lot of time by letting applicants filter their searches to companies using methods that will let them put their best foot forward.
I can understand that some people find whiteboard coding really stressful. I never have, and I have found take-home assignments to be a huge time-sink which typically results in minimal feedback (and sometimes none at all).
Maybe the right thing to do is to just give interviewees a choice.
This is a true snapshot of the absurd sense of entitlement among some tech workers these days. When the bubble eventually pops, people will look back at this website promotion with awe.
It's like challenging the generally accepted standard that interviewees dress up a bit more formally than a typical day at the office (i.e. button down versus old T-shirt).
This just creates elitism where the "senior" developers get nice hiring processes, and the junior developers get stuck with traditional torture.
Whiteboard questions are okay. Only giving tasks is not how a real workplace work
Furthermore, whiteboards are great communication tools. I spend some time on VRChat's whiteboard room teaching people various algorithms, and other abstract things to help me learn. Someone who knows how to use a whiteboard and communicate correctly would be a better hire than someone who doesn't.
If the company you work at uses whiteboard problems to vet interviewees, just drill them. With a little practice, you'll have a better chance.