Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hiring without whiteboards

github.com

Post reply on HN
Print view View original

261–270 of 372 posts

Re: Hiring without whiteboards

#261

Post by detaro »

digler999 wrote: post #258
ryandrake wrote: post #225

Earlier quoted context omitted.

Thank you. A great response to "reverse a string" is "What's the encoding?" If it's anything but ASCII, you're in for a long white boarding session. If the interviewer doesn't know what you're talking about, back away slowly......

what makes other encodings hard ? The two things that come to my mind are byte length and comparison function. If the encoding had a fixed-length byte length, then it should be just swapping n-bytes at a time instead of 1-byte. What else is difficult about non-ascii encodings ?

e.g. in UTF-8 a codepoint is encoded in varying byte lengths (so you have to split into codepoints and then reverse), and, a lot more difficult, a sequence of multiple codepoints can be combined to form a symbol. Simplest case would be something like "ö" encoded as "o" (U+006F) followed by a combining diaeresis (U+0308).

Other fun special cases: 🇺🇸 is U+1F1FA REGIONAL INDICATOR SYMBOL LETTER U, followed by U+1F1F8 REGIONAL INDICATOR SYMBOL LETTER S and should if possible be displayed as a US flag (otherwise falls back to text "US"), should reversing it create 🇸🇺 (replacing the flag with the characters "SU"), or still show the flag? (I'm not even sure if there isn't a case where both are valid country codes and it would change to a different flag?)

Similarly, Emoji can be formed from a sequence with combining characters inbetween, which don't display correctly if reversed codepoint by codepoint.

Re: Hiring without whiteboards

#262

Post by ryandrake »

woah wrote: post #253
ryandrake wrote: post #224

Earlier quoted context omitted.

Additionally: Nine times out of ten, you shouldn't be implementing the binary tree in the first place. There are already tons of tested, robust libraries out there that will do it a lot better than you can, handling all conceivable edge cases, available in a variety of license flavors. Many languages' standard libraries include support for binary trees. You want candidates who can work through the buy-vs-build tradeo…

It's obvious that they're not going to use the code you wrote at an interview in production. So "just use a library" is not a relevant answer. The question was probably posed to give you an interesting engineering challenge to work through with the interviewer so that they could see your problem solving process. Instead you just argued with the interviewer.

The GP's point (which I supported) is that it's a waste of time to take a candidate through scenarios that are not at least similar to what they'd actually encounter doing the actual job.

Re: Hiring without whiteboards

#263

Post by lj3 »

bogomipz wrote: post #12

I would like to see a compilation of companies that aren't requiring a "coding project" as part of their interview process. I much prefer to write on a whiteboard as part of an onsite interview than to do a "coding project" for every single company that "might" be interested in me. My experience lately has been an immediate request to complete a coding project right after speaking to a recruiter but before speaking t…

You might be interested in this: http://they.whiteboarded.me/companies-that-whiteboard.html

Re: Hiring without whiteboards

#264

Post by badminton1 »

logfromblammo wrote: post #197
badminton1 wrote: post #155

Earlier quoted context omitted.

Well, if you did relatively fine they might still contact you in the future for other positions.

I can't tell if you're being facetious or if you're really that naive. No company that I have worked for has ever said, "You know what? Let's look at the resumes of previous applicants, call them up, and see if they are still looking for new jobs." Every vacant position is always filled by direct, active applicants. Even backchannel applicants have to send a fresh copy of their resume to someone, so that it can be ad…

I'll ignore the insults and proceed to refute your point.

I am regularly contacted by recruiters from companies where I've interviewed successfully (with offers) and unsuccessfully (no offer).

They do it because it's cost efficient.

The book "Cracking the coding interview" also speaks about this in the early chapters.

Re: Hiring without whiteboards

#265

Post by nostrademons »

gkop wrote: post #254
nostrademons wrote: post #247

Earlier quoted context omitted.

I don't think that's true, actually. I've been both interviewer and interviewee, almost all my friends do interviews, and in every case I've seen, the interviewer is earnestly trying to make her best determination of whether you can succeed at the company. Most interviewers - both ones I know as friends and ones that have interviewed me - get very, very happy when they find a candidate that they know will meet the hi…

Sometimes it's worth taking action to diminish a perception, even if that perception isn't actually true. Has Google considered the impact of the perception that their interviews are hazing? Especially in the context of Google's public commitment to increase diversity among their engineers, it strikes me that revamping their interviewing process to eschew whiteboarding ought to at least be considered - it would be am…

I'm not certain that an interview process without whiteboarding - or at least some other form of coding test - would actually be able to detect the skills Google needs in their interviews.

I see comments on HN time to the effect of "Why do I need to know how to traverse a tree or sort a trillion 32-bit integers? Why should I care about big-O notation? When will I ever use those skills on the job, when I could just Google for a standard library function?" I used those skills all the time when I worked at Google. When your data set is measure in petabytes, you can't just reach for a stdlib function, you have to actually know how the algorithm works, in depth, so you can implement it across thousands of machines. And any algorithm slower than O(N log N) is not going to work. Even in frontend work, I used tree traversals all the time because JQuery's byte cost was too high to use on Google services.

They have been taking other steps to increase diversity, though, like redacting names & genders on resumes, ensuring that every female candidate has at least one female interviewer, and trying to source candidates from non-traditional (i.e. non-Ivy-league, non-brand-name-tech-company) places.

Re: Hiring without whiteboards

#266

Post by enraged_camel »

ninjakeyboard wrote: post #215
lhnz wrote: post #185

Earlier quoted context omitted.

Part of this is that a lot of interview practices (including whiteboarding) exclude people that suffer from social anxiety. Just because somebody freezes up when being watched and critiqued by an Evaluator, doesn't mean that they are 'copy-and-paste programmers'. There are probably a lot of extremely good engineers who find this style of interview difficult. People that call 'whiteboarding' a skill don't really get i…

"People that call 'whiteboarding' a skill don't really get it. If you have irrational fear over people's judgements and this manifests when you're being interviewed, you can't merely expose yourself to this fear often to lessen it. It is very difficult to change how your mind and body react to uncomfortable situations. " I disagree on a few levels. I can't back anything with data but I'll point to where you can find…

>>Being able to talk and interact with people is a part of the role. Software is not written in isolation - it is done best with a lot of collaboration and critical review of work. Being able to communicate and give and receive critical feedback are cornerstone traits. Good code is not written in isolation and giving and receiving critical feedback is not comfortable.

There is a difference between collaborating and receiving critical feedback from a fellow coworker, and being evaluated by an interviewer (or worse yet, a group of interviewers) who might or might not offer you a job (since your livelihood depends on that). That's why people who are typically comfortable working with others can become extremely anxious during whiteboard interviews.

Re: Hiring without whiteboards

#267

Post by SomeStupidPoint »

746F7475 wrote: post #259
SomeStupidPoint wrote: post #256

Earlier quoted context omitted.

In what way do you think whiteboards are like deadlines? I honestly don't understand this line of thinking. It's not about "pressure", it's about the fact I'm an introvert and do poorly at composing while speaking. My brain requires time to focus inward to formulate complex thoughts, and interrupting any time I pause narrating doesn't give me that time to think. I've literally never had it be an issue in my career, b…

>My brain requires time to focus inward to formulate complex thoughts, and interrupting any time I pause narrating doesn't give me that time to think. So basically what you are saying is that you are some kind of snowflake that requires it's own room to concentrate and be productive and you can't even think while doodling on a whiteboard. In my books that counts against you, that doesn't mean you are straight out, bu…

Not even remotely.

What I said is that I share a trait with about 25% of the population, more in software, where I can't do my best composing if I'm narrating at the same time. By "time", I mean 30-120 seconds without having to speak.

In actual development that doesn't matter: pauses to compose an answer are fine in conversations and most work time is individual anyway (even in open offices).

I do note, however, you didn't actually answer my question: in what way is whiteboarding like real work deadlines?

Re: Hiring without whiteboards

#268

Post by nolemurs »

ciqsteve wrote: post #158
ninjakeyboard wrote: post #110

What's with all the whiteboard backlash? I ask simple questions and expect people to be able to write code unaided to express their idea. Not "implement a linked list" or "write quicksort" but basic "You have two arrays - find if a number exists in both arrays" sort of thing, primarily to reason about runtime complexity, and to make sure they can actually write code. If you tell a candidate to prepare, they should be…

Whiteboarding itself is a skill. What I learned the hard way: - There is no insert. If you need to go back and insert a line of code somewhere you must either erase all the code below it to make room (then rewrite said code), or you draw a line from the insertion point to somewhere else on the white board and write the code there. For the former you waste a lot of time. For the later the code quickly becomes hard to…

I absolutely agree that whiteboarding is a skill that requires practice. That said, with a reasonable interviewer, the first couple things you're discussing really don't matter. The trick is to understand that no one cares if you're actually writing working code, and that the important thing is communicating your intentions and process.

> There is no insert.

This really isn't a problem. If you need to insert a line, in most cases you can just draw an arrow and then describe what you forgot to do there. Code may not even be necessary. Anyway, an arrow is fine.

> There is no context driven autocomplete or quick method lookup

Again, not really a problem. Just say "I forget the method name here, I'm just going to assume it's called 'append'" (or some other appropriate name). No reasonable interviewer cares in the slightest as long as it's clear you know what you're doing and it makes sense.

> If you code iteratively the whiteboard is not your friend.

This is absolutely an issue. Everyone codes iteratively though. Successful whiteboarders learn to do the iterative part of coding verbally instead of in code. You talk through the algorithm you're going to implement, and refine your plan in words, and then only when you've got a solution you're happy with do you pick up the marker. As a side benefit, this demonstrates your thought process much better than coding would. Actually, this is just a better flow even for development on your own computer. Once you develop the skill, you'll find that a little more planning time before you touch the keyboard almost always leads to faster implementation overall.

Re: Hiring without whiteboards

#269

Post by kelvin0 »

Imagine this. You are interviewing for a job, you walk in a room with 2 people who hand you over a sheet with a few problems. They ask you to write the solutions on the whiteboard, while they wait for you to complete.

Not a word is said, they are clicking at their laptops, and staring at the whiteboard, as waiting for the genie to pop out of a bottle. All the while your mind is frozen and stuck in a bad loop.

This lasts an hour, you are barely able to complete parts of the problems and are frozen. Of course this affects your usually creative and sharp mind.

The torture lasts an hour, time's up! You shake their hands, as a kiss of death, and head out. As you are walking back, all the answers to all the problems they wanted you to whiteboard, come rushing like a torrent in your mind. Too bad, another 'botched' technical interview.

This is my experience as a battle tested developer who is shipped many products and has been programming for the love of computers since the age of 12 (professionally for more than 15 years). I am not going to be working at Google any time soon (not that a Google job really matters to me).

Re: Hiring without whiteboards

#270

Post by toephu2 »

silverbax88 wrote: post #198
ninjakeyboard wrote: post #110

What's with all the whiteboard backlash? I ask simple questions and expect people to be able to write code unaided to express their idea. Not "implement a linked list" or "write quicksort" but basic "You have two arrays - find if a number exists in both arrays" sort of thing, primarily to reason about runtime complexity, and to make sure they can actually write code. If you tell a candidate to prepare, they should be…

You'd better be looking for psuedocode, because if you're looking for syntax, no strong programmer with experience is going to take you seriously. Honestly, whiteboard interviews are for lightweight startups with very little programming knowledge. You should be looking at logic, not syntax. You should be looking at how the person thinks, not if they can memorize a specific language to do a simple task.

Have you ever interviewed at Google? They care about syntax, psuedocode will not cut it in the interviews... and Google has a lot of strong programmers.
Post reply on HN