Live data from Hacker News

A listing of companies that don't do whiteboard job interviews

github.com

201–210 of 243 posts

Re: A listing of companies that don't do whiteboard job interviews

#201
I've written a script to allow me to filter the list, using the Functional Perl libraries. Maybe someone will translate it to JS?

https://github.com/pflanze/functional-perl/blob/master/examp...

If you want to run it:

    sudo apt-get install libfunction-parameters-perl libterm-readline-gnu-perl libpadwalker-perl
    git clone https://github.com/poteto/hiring-without-whiteboards
    git clone https://github.com/pflanze/functional-perl
    functional-perl/examples/hiring-without-whiteboards --help
    functional-perl/examples/hiring-without-whiteboards hiring-without-whiteboards/
E.g. to search for companies that offer remote jobs but not also jobs in London, UK:

    $cs->filter(fun($r) { $r->remote and not $r->locations->any(fun($l) { $l=~ /\bUK\b/ and $l=~ /london/i }) })->show_items
Disclosure: I'm the author of the Functional Perl libraries.

Re: A listing of companies that don't do whiteboard job interviews

#202
post #92

Earlier quoted context omitted.

If you're testing for their coding process, why do you make them write it out on a whiteboard? Why not provide them a code editor or at least text editor? I like whiteboard interviews, but they should be testing high level design ("describe solution in words / detail in pseudocode"), not coding skills.

How is providing a code editor or text editor different than writing it out on the whiteboard? I do a similar process and don't care if their syntax is exactly correct. I, maybe different from the person you're responding to, don't care if they use exact libraries in the precisely correct way. But I do care that they're able to come up with a plausible solution. At a point, I see people gripe about whiteboard intervi…

The process of scribbling characters with a marker on a whiteboard is quite tedious and takes up a lot of time and effort. And doing it feels more akin to multitasking than a normal coding process, since so much of the effort goes into scribbling out things (as opposed to the actual coding process). Ability to draw glyphs on a whiteboard will become a confounding factor here.

Being able to type out things in a text editor simply makes the interview process much more efficient.

Note: I share your annoyance with people who gripe about whiteboard problems and algorithms / data structures problems not being representative of everyday work.

Re: A listing of companies that don't do whiteboard job interviews

#203
As a lefty, my biggest problem with whiteboard interviews is writing code on the whiteboard. I just can't write text in straight lines very easily because my hand is occluding it, and so I write slower and use more strength doing it, getting tired pretty quickly. I have no problem drawing on a white board (I draw my shapes in counter directions like most lefties), or writing simple labels/lists, or whatever, but coding on a freaking whiteboard should be illegal :).

And then they expect me to talk while writing code on the whiteboard...

Re: A listing of companies that don't do whiteboard job interviews

#204
Sorry, this is too black-and-white.

Of course it's stupid to ask somebody to write down red-black-tree rebalancing algorithms from memory. Especially on the whiteboard without any syntax/compiler help.

But given a more-or-less concrete basic problem that every programmer should be able to solve with just basic knowledge of the chosen language hands-on (at a computer, not the whiteboard) is a different thing. It can be a collaborative process where the candidate can sketch an approach on paper/whiteboard, then write code. While doing that they can query API question to the interviewer, which, if they are doing a good job, will be giving that information willingly. Watching the candidate building their solution towards something that works tells a lot. It's not just whether the code works. It's communication too. Code organization. How they think, how they approach a problem, what to do when they get stuck (ask for help? run in circles? just get confused?), what do do when their code has a bug etc.

Take-home exercises seem to be praised as the key solution, but I think that's fundamentally flawed as already discussed here. If done badly, it's just as bad as from-memory-whiteboard stuff. In-person-problem-solving can be done quite well.

And the market proves that it works. Successful companies do it. If their hiring would suffer substantially, then they'd have stopped doing it, because their competition would have a substantial edge.

Re: A listing of companies that don't do whiteboard job interviews

#205
post #84

Earlier quoted context omitted.

If 'Work Hours' require someone to be oncall 24/7, you can ask that as part of your interview, but you can't infer that from other factors. Yes: "Our job requires you to be on-call 24/7, one week a month, can you commit to that?". No: "You said you didn't have time for the take home test because you have a family. The family will get in the way of 24/7 support" Also yes: "you will be traveling 5 days a week for your…

As someone who has been in this industry for a long time and seen a lot, this still baffles me. Who agrees to being on call 24/7 for a week? Especially when you are getting paid a typical professional salary? It seems absurd. I've always been active after hours and willing to jump in when things happen. But this idea that you are essentially working (since you need to always be somewhere you can start working within…

I do call one week in 10. I typically have between one and three out-of-hours pages during this time. A typical page takes 20 minutes to deal with, although sometimes they do take longer.

30-minute response time means I can still do things like skiing or hiking during on-call weekends, if I'm a bit creative.

As a result of doing call, my team's product runs reliably and meets its SLA requirements, allowing my company to sell the product to other serious companies and therefore for my job to exist.

I get paid around $4k for each week of this (on top of my normal salary). It is worth it for me.

I have "other interests and people in my life", including a girlfriend, friends, outdoor adventuring. One week in ten hardly affects anything, and I can usually trade with a teammate if I want to go away a particular week. Most of my friends have their own careers which make far more onerous demands on their lives for less compensation (doctors, lawyers, nurses, restaurateurs).

Re: A listing of companies that don't do whiteboard job interviews

#206
post #47

The theoretical coding interview based on undergrad CS topics has become a cottage industry by itself with books,online sites etc. Very few people know that this is used for indirect age discrimination to favor young folks. Not sure when this insanity will stop. Human beings went to moon before we had this coding interviews.

And what makes older folks incapable of solving questions using basic algorithms and data structures?

Re: A listing of companies that don't do whiteboard job interviews

#207

Earlier quoted context omitted.

I agree with all of your examples - it is discrimination if an employer says "your family will get in the way of you working off hours." What I find obnoxious, though, is when an employer has standard rules for everyone (e.g. "all prospective applicants must produce a 3 hour at home project as part of the interview process") and then balk at "discrimination" because you'd rather spend your time at your kid's soccer g…

I work 10 hours a day, my wife does as well, and we start at substantially different times. We have a child who can stay up until 11. If I'm doing multiple interviews (which everyone should be doing) and each requires 3 hours of my time (generous underestimate) then what am I going to do? Hire a sitter for a potential job for each of these companies? Give me whiteboarding interviews -- at least the studying is cross…

> then what am I going to do? Hire a sitter for a potential job for each of these companies?

Yes, why not? For many people taking time off their existing job during the work day to interview is difficult, but they find a way to do it.

My whole point in this thread is not that interviewing isn't onerous, or that some companies may require more of a time investment than some people are willing to make (and, if that's the case, it's fine to say that job/company isn't for you). What I find obnoxious is when people turn their unwillingness to spend time on the interview or homework as "you are discriminating against me because I am older or because children."

Re: A listing of companies that don't do whiteboard job interviews

#208

There are many comments in this thread about whiteboard vs take-home programming challenges. That's a false dichotomy. What I would really like to see is an interview where I am allowed to code on a computer (at the interview) instead of a whiteboard. I would like to be able to write real code, and test it while I'm coding, as I normally do when programming.

Yeah, this has started becoming the norm at a lot of startups - coding on computer + design on whiteboard, and I think it works really well.

Re: A listing of companies that don't do whiteboard job interviews

#209

Earlier quoted context omitted.

That's if your used to using your laptop not your desktop, you didn't forget to charge it, the WiFi is working, you aren't missing your mouse keyboard montitor, etc. Ive had candidates many fuck all that up and spend 15 minutes fixing the ergonomics. Guess what it's a 25 minute coding exercise, good luck. If I give them a laptop, same deal. After it all I still give them the option. Their computer ours or whiteboard.…

I'll admit this mostly comes from frustration standing by a whiteboard. If I did the same thing on a computer, I'd maybe just have a different set of frustrations. As someone who does a lot of TDD, I is quite frustrating that a whiteboard can't run tests though... What I have seen work well, from both sides, is interviewing by pair programming. Not for everyone, for sure.

Just write the test cases as bullet points and actually run through the algorithm with them when done coding. Don't declare success the instant you wirte that last curly.

Doing that gets a big plus from me (I'm 100% tdd personally).

Remember I know the answer to the question. The instant I can tell you do and for reasoning is good, I'm going to stop waisting time getting fro 95% sure to 100% sure on that part of the question and get another piece of data.

Usually that for me is to add some system design, speed consideration or other area of investigation and try to get another overall compentency covered. And just keep doing that till we run out of time.

It's very often other interviewers aren't able to hit things so backup signals are great.

And interviews are risk mitigation really. The more 80% certainties I can get on the more areas of coverage the Better if the interview team is doing a good job.

Post reply on HN