1. 16
  1.  

  2. 13

    I appreciated that the author described whiteboard interviews as a “hazing ritual”. That’s exactly what it felt like the last time I endured one.

    1. 6

      I’ve been conducting whiteboard data structures & algorithms interviews for a few months now. (We also give them laptops if they want to type on them.) I think they’re somewhat fair, given alternatives. I don’t ask trivia questions. My questions are pretty simple, with a progression of several possible solutions, each more efficient than the other. They’re the sort of problems I have solved in the past. (No dynamic programming stuff or whatever.) I do expect a candidate to know their language and basic CS concepts really well. They should be able to give solid reasoning for big-O. I do think it’s necessary to know the basics of big-O analysis. Bonus points for knowing standard library APIs well, but no big deal otherwise.

      I don’t read resumes before the interviews. I don’t want to add extra bias. I ask a quick question about their technical experience at the beginning. This question is just to gauge general communication skills. At the end of the interview, I write up a summary of what happened. Those are sent to a committee which makes the decision.

      This approach is standardized, which means individual biases are minimized.

      Requiring open source contributions or take-home work unduly burdens those with families or other care-taking work. I prefer not looking at resumes so I’m not biased toward good universities or companies.

      1. 1

        They should be able to give solid reasoning for big-O. I do think it’s necessary to know the basics of big-O analysis.

        I’d argue that if someone is familiar with big-O but not with profiling, their knowledge is as good as nothing. Premature optimization is the bane of software development.

        I ask a quick question about their technical experience at the beginning. […] I prefer not looking at resumes…

        Couldn’t you glean the same knowledge by looking at their résumé?

        1. 2

          I’m with you on big-O. It’s only a starting point for real performance engineering. I try to get to the nitty-gritty details of how their solution would work in a real system after they finish the main problem. Hopefully, they have some real-world knowledge about how their solution works.

          Well, the way we do it, the question at the beginning is just for me to gauge communication skills and get them comfortable. By the time they’ve gotten to me, the resume has been vetted at a basic level. Later on, someone will take my feedback and the resume into account to make the final decision. I think the anti-bias reason for not reading resumes is more important than the slight changes I can make to my algorithmic questions to account for their experience.

      2. 5

        I’m trying to convince my workplace to get rid of whiteboarding interviews, does anyone know if there are resources for ideas of alternatives? Anyone have a creative non-whiteboarding interview they’d like to share?

        1. 7

          The best that I’ve found is to just ask them to explain some tech that’s listed on their resume. You’ll really quickly be able to tell if its something they understand or not.

          My team does basic networking related stuff and my first question for anyone that lists experience with network protocols is to ask them to explain the difference between TCP and UDP. A surprising number of people really flounder on that despite listing 5+ years of implementing network protocols.

          1. 6

            This is what I’ve done too. Every developer I’ve ever interviewed, we kept the conversation to 30min-1hr and very conversational. A few questions about, say, Angular if it was listed on their resume, but not questions without any context. It would usually be like- “so what projects are you working on right now? Oh, interesting, how are you solving state management?” etc. Then I could relate that to a project we currently had at work so they could get a sense of what the work would be like. The rapid-fire technical questions I’ve find are quite off-putting to candidates (and off-putting to me when I’ve been asked them like that).

            As a side note, any company that interviews me in this conversational style (a conversation like a real human being) automatically gets pushed to the top of my list.

            1. 4

              Seconded. Soft interviewing can go a long way. “You put Ada and Assembler on your CV? Oh, you just read about Ada once and you can’t remember which architecture you wrote your assembly for?”

              1. 3

                I often flunk questions like that on things I know. This is because a question like that comes without context. If such a problem comes up when I’m building something, I have the context and then I remember.

                1. 6

                  I don’t think any networking specialist would not know the difference between TCP and UDP, though. That sounds like a pretty clear case of someone embellishing their CV.

                  1. 4

                    So if you can’t whiteboard and you can’t talk about your experience, what options are left? Crystal ball?

                    1. 3

                      I like work examples, open ended coding challenges: Here’s a problem, work on it when you like, how you like, come back in a week and lets discuss the solution. We’ve crafted the problem to match our domain of work.

                      In an interview I also look out for signs of hostility on the part of the interviewer, suggesting that may not be a good place for me to work.

                2. 5

                  A sample of actual work expected of the prospective employee is fair. There are pros and cons to whether it should be given ahead of time or only shown there, but I lean towards giving it out in advance of the interview and having the candidate talk it through.

                  Note that this can be a hard sell, as it requires humility on the part of the individual and the institution. If your organization supports an e-commerce platform, you probably don’t get to quiz people on quicksort’s worst-case algorithmic complexity.

                  1. 7

                    I certainly don’t have code just sitting around I could call a sample of actual work. The software I write for myself isn’t written in the way I’d write software for someone else. I write software for myself in Haskell using twenty type system extensions or in Python using a single generator comprehension. It’s for fun. The code I’ve written for work is the intellectual and physical copy of my previous employers, and I couldn’t present a sample even if I had access to it, which I don’t.

                    1. 5

                      Yup, the code I write for myself is either 1) something quick and ugly just to solve a problem 2) me learning a new language or API. The latter is usually a bunch of basic exercises. Neither really show my skills in a meaningful way. Maybe I shouldn’t just throw things on GitHub for the hell of it.

                      1. 4

                        Oh, I think you misinterpreted me. I want the employer to give the employee some sample work to do ahead of time, and then talk to it in person.

                        As you said, unfortunately, the portfolio approach is more difficult for many people.

                        1. 1

                          I write software for myself in Haskell using twenty type system extensions or in Python using a single generator comprehension. It’s for fun.

                          Perhaps in the future we will see people taking on side projects specifically in order to get the attention of prospective employers.

                      2. 3

                        I recently went through a week of interviewing as the conclusion of the Triplebyte process, and I ended up enjoying 3 of the 4 interviews. There were going to be 5, but there was a scheduling issue on the company’s part. The one I didn’t enjoy involved white board coding. I’ll tell you about the other three.

                        To put all of this into perspective, I’m a junior engineer with no experience outside of internships, which I imagine puts me into the “relatively easy to interview” bucket, but maybe that’s just my perception.

                        The first one actually involved no coding whatsoever, which surprised me going in. Of the three technical interviews, two were systems design questions. Structured well, I enjoy these types of questions. Start with the high level description of what’s to be accomplished, come up with the initial design as if there was no load or tricky features to worry about, then add stresses to the problem. Higher volume. New features. New requirements. Dive into the parts that you understand well, talk about how you’d find the right answer for areas you don’t understand as deeply. The other question was a coding design question, centered around data structures and algorithms you’d use to implement a complex, non-distributed application.

                        The other two companies each had a design question as well, but each also included two coding questions. One company had a laptop prepared for me to use to code up a solution to the problem, and the other had me bring my own computer to solve the questions. In each case, the problem was solvable in an hour, including tests, but getting it to the point of being fully production ready wasn’t feasible, so there was room to stretch.

                        By the time I got to the fourth company and actually had to write code with a marker on a whiteboard I was shocked at how uncomfortable it felt in comparison. One of my interviews was pretty hostile, which didn’t help at all, but still, there are many, far better alternatives.

                        1. 1

                          I’m a little surprised that they asked you systems design questions, since I’ve been generally advised not to do that to people with little experience. But it sounds like you enjoyed those?

                        2. 1

                          There are extensive resources to help with the evangelism side of things.

                        3. 4

                          I’m in my favorite job of my career so far, doing my best ever work. I had a very reasonable interview loop without a single trivia question. It’s the first time I got referred in by a friend and ex-coworker, through a network of his friends.

                          My new rule of thumb for myself is, when possible, work with my friends or their friends. Referrals referrals. Find people you like to work with and stick together. The only way to know if somebody can solve real problems for a real company (with warts and all) is by actually being in the trenches with them for months and years.

                          1. 5

                            Working only with friends and friends of friends seems wrong to me. The words that come to mind are exclusive and cliquish. To get diverse perspectives and live up to the ideal of equal-opportunity employment, we need to be comfortable working with strangers.

                            1. 3

                              Traveling between companies as a group of friends doesn’t mean that you’re only working with said friends, since there will almost always be other co-workers involved, but that you’re working with more known quantities. As an employee-side strategy, I don’t think it’s hugely problematic, especially given the amount of information asymmetry that’s often in play in hiring. I’ve also had luck with referrals (I’ve found out about 3 out 4 of my development jobs via some sort of reference or connection, including my current one).

                              On the employer side, I could see only working with referrals being somewhat problematic, but I doubt most employers do that.

                              1. 2

                                I mean, my friend’s friend who I am now working for is roughly 3000 miles away from where I met my friend. I was definitely exposed to diverse perspectives by moving out here, and I necessarily have to interact and learn from all of my new coworkers (who are all diverse strangers to me). What I gained was a pre-selection stamp; somebody vouched that I’m not an idiot.

                                It’s also bi-directional preselection. I know that my friend wouldn’t send me off to work for a real dumpster fire of a company - I know that I’ll be working with good people on good projects, and it would benefit my own personal growth.

                                Friend networks can span multiple cities, countries, companies, and cultures. It doesn’t have to imply inbreeding.

                                The words that come to mind are exclusive and cliquish.

                                This sounds fun in practice until you hire a terrible stranger. Then you’re back to square one of “how do you find out if an interview candidate is good?” And it’s a hard question.

                            2. 3

                              ProTip: after you finish the whiteboard puzzle the interviewer gave you, turn around and give them a puzzle to solve.

                              1. 2

                                Given how good fluid reasoning is of a predictor of complex job performance, I wonder if a battery of novel logic problems in a programming veneer would be a good substitute for traditional initial employee screenings. Then the remaining candidates could get evaluated on a paid take-home task that replicates what the actual work would be as much as possible.

                                It would be great to just go straight to work-like tasks to evaluate prospective employees, but it’s costly, time-consuming, and will filter out candidates that won’t make that much of a commitment on first contact.

                                I, personally, won’t do any take-home work without the prospective employer also having invested something in the process. For all I know, my 2-hour project has been given to 100 other candidates, and there’s a good chance they’ll decide they don’t actually need to hire that position and not look at a single one.

                                1. 2

                                  I buy into your premise that fluid intelligence correlates with complex job performance, but how many of us work in truly “complex jobs”?

                                  For churning out stylish CRUDs and ticking off tasks from a backlog, there’s very little fluid intelligence required. Ability to focus and deal with the occasional boredom would be a much better predictor, I conjecture. Concretely, you can probe for this by asking candidates about projects they’ve been working on and making sure there’s at least a handful of them that they’ve taken to completion.

                                  1. 4

                                    I think machines are coming for the sort of tedious jobs that only require work ethic, i.e. the ability to focus and get through boredom. If that’s so, we’ll only be left with the complex jobs that require real intelligence.

                                2. 1

                                  I might be in the minority here, but I don’t mind whiteboard puzzles. I’m not saying they’re effective as a hiring tool (I’m also not not saying that), but I’m always surprised when people say they stress specifically about them over other interview methods. I’m genuinely curious what exactly people dislike (other than ‘it’s not representative of the job’, which I agree with). Is it the stress and time pressure? Or the reliance on past knowledge? Would it be possible to construct a good whiteboard interview for you, or is the format itself distasteful?

                                  1. 4

                                    I think for the majority it’s because a lot of their knowledge is stored on the internet with their working memory copy simply being how to quickly look up the documentation to get the right answer.

                                    I think for the majority it’s because the internet has become an extension of their working memory and without it they flounder simply because they haven’t needed to commit to memory the details, or anything much more than were to find them when needed.

                                    The best analogy I can come up with is mental arithmetic, it used to be that you could take someone to the white board and ask them to work out a long division question or complex multiplication and most would be able to do so with little to no stress. With the prevalence of calculators nobody bothers to remember how to do long division or factorisation of difficult multiplication because they know how to use a calculator that does it quicker (we are animals of path of least resistance after all.)

                                    A white board interview where you’re describing abstract concepts would probably solve a lot of the worries, because that tends to be what most people remember, with the details filled in by a few searches of the documentation.

                                    1. 4

                                      A white board interview where you’re describing abstract concepts would probably solve a lot of the worries, because that tends to be what most people remember, with the details filled in by a few searches of the documentation.

                                      This makes sense to me – I feel like if you handed someone a marker and said “explain {something from their resume} to me,” a whiteboard interview would be a lot less intimidating.

                                      1. 2

                                        I’d certainly expect people to be able to do a long multiplication on a whiteboard, though. It’s pretty standard stuff. If they couldn’t, I’d hope it was due to a mind blank under stress and not because they literally don’t understand how multiplying numbers works.

                                        And I think that if you can’t do basic programming without the internet you’ll struggle to be productive. That’s not to say that you should just know everything, but far too many people I’ve seen can’t do any little basic bit of programming without googling the most basic things. I like that programming competitions, if nothing else, at least force you to learn to write the basic ‘glue’ code quickly without having to look up e.g. how to print something to two decimal places or how to read a float from standard input. Basic stuff you should just know. They also are an okay litmus test. I’ve never met anyone that did well in programming contests that was a bad programmer. But I’ve definitely met good programmers that didn’t do programming contests. It has a high false negative rate and a very low false positive rate, I expect.

                                        1. 3

                                          I personally haven’t had to do long multiplication on paper in well over a decade and while I can describe three different methods in abstract I wouldn’t be able to do them without looking up simply because I have forgotten the details over the years of resolving to use a calculator.

                                          The same can be said for some with programming, maybe they use a framework that provides verbose abstractions but no longer remember how to do such things (e.g sessions, http, file handling) on “bare metal” without first looking it up.

                                          Having a decent memory isn’t a bad thing but as Einstein supposedly once said “Never memorize something that you can look up.”

                                          1. 5

                                            Einstein probably never said that. However he did say. (In response to not knowing the speed of sound as included in the Edison Test: New York Times (18 May 1921); )

                                            [I do not] carry such information in my mind since it is readily available in books. …The value of a college education is not the learning of many facts but the training of the mind to think.”

                                            Basically don’t labor over learning dumb facts. I also though think it’s wise if you find a free moment to understand how and why things work.

                                            1. 3

                                              That is a much better quote, it also encompasses what milesrout was saying in a separate thread.

                                              1. 2

                                                It’s also likely that Einstein never said “Never memorize something you can look up”, so it’s not really fair to call it a quote. If you had to create a pithy new phrase from his quote it might be something like “Facts are no substitution for reason and understanding.”

                                                1. 2

                                                  That is the reason for why I wrote “Einstein supposedly once said”; I wasn’t trying to pass off something that may not be true as fact. However it is certainly something that a small amount of searching found to be a popular phrase attributed to Einstein and that is the reason why I quoted it.

                                                  The New York Times reference you provided was much better not only in being easily traced back to the man himself but also because it better conveyed the point I was trying to make. Thank you for sharing it :)

                                                  1. 2

                                                    Yes, sorry for being pedantic. I just wanted to make sure I wasn’t being misunderstood there. I had assumed that you said it in good faith. Thank you for being patient.

                                            2. 2

                                              The ‘details’ are essentially that 2134 * 34 = 2134 * 30 + 2134 * 4. I really don’t think you’d have any trouble if you thought about it for a few seconds.

                                              The problem I’ve seen is that people don’t even think about something. They either know it and do it or they convince themselves they don’t know it and don’t try to work it out. That, the predilection to giving up, that is the danger sign, not that they don’t know it.

                                              The same can be said for some with programming, maybe they use a framework that provides verbose abstractions but no longer remember how to do such things (e.g sessions, http, file handling) on “bare metal” without first looking it up.

                                              I mean if you’re doing high level stuff you shouldn’t expect to know the details of writing low level code. If people are testing your algorithm knowledge at a Javascript webapp gig, then it’s just bad interviewing. But people testing your algorithm knowledge at a routing algorithm gig seems pretty fair.

                                              Having a decent memory isn’t a bad thing but as Einstein supposedly once said “Never memorize something that you can look up.”

                                              But if you asked Einstein some basic physics he wouldn’t look it up, he’d know it. Because having fully internalised the basic principles of physics is just part and parcel of understanding physics at the level he understood physics. Like, if you asked a mathematician the epsilon-delta definition of a limit, they’d be able to explain what it is, and what it meant, even if perhaps they couldn’t write it down formally left to right in one go if they hadn’t recently taught a course on analysis. Not because they’re geniuses that remember everything but because it’s just the most basic fundamental knowledge that everything else is based on.

                                              1. 5

                                                I think we are both on the same page, possibly I am bad at explaining what I am trying to say.

                                                people testing your algorithm knowledge at a routing algorithm gig seems pretty fair

                                                Agreed, the problem I think many see with white board interviews is that they are largely used to test knowledge that isn’t pertinent to the job at hand for example testing your algorithm knowledge at a job where you’re largely expected to write high level web apps where everything is wrapped in an closed source abstraction you’re going to need to learn on the job anyway.

                                                1. 1

                                                  Exactly. They used to test how an individual candidate goes about problem solving, but nowadays they’re just a litmus test to see if you’ve memorized all the graph algorithms you might be asked to regurgitate.

                                                2. 3

                                                  But if you asked Einstein some basic physics he wouldn’t look it up, he’d know it.

                                                  All of my physics professors and PIs looked basic stuff up all the time. There’s a reason we were allowed to take two pages of equations into exams.