131–140 of 243 posts
If you find yourself here, stand up for yourself. Say you have a number of interviews going on and that you are happy to do a 2-3 hr assignment (the same as an on-site interview).
Earlier quoted context omitted.
The linked list is such a fundamental piece of technology that you never have to implement it. I mean, I understand the linked list quite well, but in my multi decade software career, I've probably actually implemented one less than once a decade. So I think it's a very unrealistic interview question, and will sigh quite hard (internally) when asked to implement one in an interview. You just can't please everyone...
I agree, if you implement a linked list in production code, you've almost certainly made a mistake. My point is that a linked list is such a simple concept that anyone with real programming experience should be able to write a basic implementation. It's a Shibboleth; I only care about your ability to perform the task because it tells me something else about you.
It almost levels the playing field in the sense that since no one actually writes these things, we're probably all equally half clumsy with them :)
Earlier quoted context omitted.
When I do whiteboard questions, its never to see someone regurgitate a common question. Its just nice to see someone solve a problem and what their thought patterns are. CS is pretty much an art, would you hire a violinist without hearing them in person?
Would you ask a violinist to draw the chords they would play on a whiteboard, or would you hand them a violin?
I ask most candidates to write code on a whiteboard in front of me and I’m not apologizing for it! The problem is usually fairly easy and if the candidate cannot get to a “describe solution in words” milestone then I will guide them to one. After that I ask them to write code. I will also tell them “the code is the part I care about”. The specific competency I am evaluating here is “can you turn thoughts into code”.…
There are some exceptional cases when giving homework is acceptable/can be useful, but if you're giving it to all applicants, you're certainly selecting for an audience that has a lot of time to spare.
I ask most candidates to write code on a whiteboard in front of me and I’m not apologizing for it! The problem is usually fairly easy and if the candidate cannot get to a “describe solution in words” milestone then I will guide them to one. After that I ask them to write code. I will also tell them “the code is the part I care about”. The specific competency I am evaluating here is “can you turn thoughts into code”.…
I've done a lot of lower level systems work and the fact is that even with a long career and history of very successful product I get whiteboard coding interviews when I look for a job ... and it's just fine. Yes it's not the same as day to day work, but it's related, and I have to admit that I find them kind of fun.
Maybe there are 2 types of "programming jobs": 1) you will have to implement data structures and algorithms, or 2) everything will be provided for you in a language or framework. For job type 2) CS is not needed - it's not a computer science related position ... it's "frameworking". I'm guessing that a lot of the whiteboard hate comes from type 2) people applying for type 1) jobs, OR type 2) companies asking type 1) questions.
For more history around whiteboard coding, there's the excellent "Why Can't Programmers Program" post: https://blog.codinghorror.com/why-cant-programmers-program/
I would like to actually figure out what is the bet way to do interviewing for coding positions but it's super hard to actually have these kinds of discussions on HN now without people getting upset at even suggesting whiteboard coding interviews.
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…
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…
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 applicable.
Its interesting how many of these companies have 'take home' challenges or projects. Even though the companies may say, "This should only take an hour", 99% of the time, it occupies my entire night/weekend, if not in coding but in thought. There's always something more you could do. Its presented as an objective test, but its very subjective, just as much as the whiteboard test. With the whiteboard test, as a candida…
Well, we have made the experience that people that are not seriously considering to take the job are filtered out by a homework. It helps both to save a lot of time and energy interviewing people.
The only way to know this for sure would be to ask half your applicant pool to do the test, and the other half to go through the exact same battery of interviews sans take home test and then see how many of the offers you extend are accepted.
Obviously this requires that you're a big enough company to split your applicants into two pools and still have a big enough sample size.
Whenever I talk to people involved in hiring about this, they balk at the idea (for okay reasons -- in theory doing that would mean less people filtered out by homework and more applicants rejected during in person interviews that take up engineer time.)
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…
Muscle memory. If you do all your coding in an IDE on a keyboard, it's quote common not to remember how to write a basic loop because at that point it is so engrained in your muscle memory that you just sort of hit the right keys.
If I gave you a foot operated keyboard and then asked you to take a typing test, would that be fair? It's still typing, it's just a different way of typing.