Hiring Without Whiteboards • Hacker News Board

Re: Hiring Without Whiteboards

#401

Post by jeffe » Wed, Jul 29, 2020, 5:13 PM UTC

gfxgirl wrote: post #322

bob1029 wrote: post #292

I am starting to think the interview is a waste of time. Sure, you want to make sure the person is more-or-less who they claim to be on the surface, but you will never really understand their capability for reasoning with your problems until they are working in your process. One of my earlier jobs dealing with code involved a very brief interview (no whiteboard involved) followed by a 6 month contract offer. The deal…

In 2012 I was told Google gets 1 million applications a year. How do you decide which 1000 of those get 6 month contract offer? How many millions of dollars in lost productivity are you willing to lose of the people who don't pass your 6 month test that you had wasting space, taking up training time, having people have to review and reject their code, etc? What will those people do who gave up their lives somewhere e…

The value is similar to that of internships - the amortized cost of a 6 month 'trial period' should be similar if not cheaper than false positives that are a lot tougher to fire so you avoid dumpster fires like Amazon's mandatory attrition rate. I also wouldn't call it giving up there lives, when they know what they're signing up for and are presumably getting paid a similar amount to the the full time role they're applying for. Now if FAANG companies try to use their reputation to get cheap labor with no intention of hiring I don't have answers to that, but I can't imagine it would be worth the cost.

Re: Hiring Without Whiteboards

#402

Post by twic » Wed, Jul 29, 2020, 5:15 PM UTC

nilkn wrote: post #203

11thEarlOfMar wrote: post #169

We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we've implemented. We ask fo…

How do you avoid awarding candidates who violate your request of no more than two hours and spend considerable time coming up with something amazing? They may still produce 100 lines of code — but those 100 lines may end up being unusually elegant, beautiful code that stumps 40 year veterans. How do you avoid punishing someone who took your requested time constraint seriously (or otherwise didn’t have enough free tim…

Something i've seen a couple of times is giving a take-home exercise, then working on it further in the on-site interview. The first stage filters out people who can't get things done even given as much time and help as they want, the second stage filters out people who can't get things done at a reasonable pace without a helping hand.

I think it's common for an on-site interview to include a reasonable chunk of programming, and using a continuation of the take-home to do that is good because it means the candidate isn't starting from scratch. Coming in warmed up should minimise noise from nerves, unfamiliarity with tools or context, etc.

Re: Hiring Without Whiteboards

#403

Post by twic » Wed, Jul 29, 2020, 5:17 PM UTC

tziki wrote: post #236

11thEarlOfMar wrote: post #169

We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we've implemented. We ask fo…

Why not time the programming task? Since it's supposed to take about two hours you could ask them to choose a two hour slot, email them the task at that time and have them return it two hours later. This wouldn't penalize people who choose to abide by the time guideline vs more dishonest candidates.

If your slot starts, and then something comes up - your elderly grandmother phones, your internet goes down, your roof springs a leak - that would be pretty annoying.

Re: Hiring Without Whiteboards

#404

Post by usgroup » Wed, Jul 29, 2020, 5:17 PM UTC

VonGallifrey wrote: post #290

usgroup wrote: post #287

Earlier quoted context omitted.

Sure but you’re bound to say that ... Find me a hiring manager than publicly says anything else. That’s kind of part of the point. I roughly recall google touting ~50% hiring success rate and that’s with a 4 interviewer, 10-15 man interview process, and undoubtedly a massive false negative rejection rate. I think some undesirable attributes are observable in fairly short screeners ; sure screen away . But I bet you t…

The reason why I say that it was an effective filter was that the majority of people flat out FAILED the coding challenge. We only send out the coding challenge to people who where successful in the first interview and still most people failed the coding challenge. I am very sure that a random selection, even after the first interview, would have been disastrous. Result is that we have not fired anyone for performanc…

There’s nothing immoral about it if you tell applicants. It’s basically how hiring for sales is done and no one is under any illusion that you won’t keep your job if you don’t perform.

The point here is more nuanced than the straw man you’re painting. Everyone that passes the interview process stays is a bad sign because it confirms something highly unlikely about the interview process: that it succeeds in generalising aptitude.

You’re right that startups can’t do it though other than through intern programmes. Lots of companies do it through intern programmes. Only the fit interns survive and get a job.

Re: Hiring Without Whiteboards

#405

Post by bananaface » Wed, Jul 29, 2020, 5:23 PM UTC

rocqua wrote: post #376

bananaface wrote: post #359

Earlier quoted context omitted.

Just look at their GitHub and if it looks good, dive in at the interview to make sure they actually wrote the code. Isolated take-home tests seem ridiculous to me if the candidate has public code available. You're filtering out anyone who likes to avoid duplicated effort.

Requiring github as a CV is worse from the POV of not forcing people to spend a lot of time outside work programming. Not everyone has the inclination or time to code outside of work. Many of these people are still very competent developers.

Sure, that's why I said "if" - if they don't have a public presence then give them a test.

But frankly I don't really buy that excuse. Those people have time for multiple coding tests but they don't have time for a (small) public project? Ehhh. Not convinced. If you can get away with no portfolio to begin with then you're not going to be inclined to accept coding assignments.

Re: Hiring Without Whiteboards

#406

Post by keanebean86 » Wed, Jul 29, 2020, 5:23 PM UTC

asdff wrote: post #249

keanebean86 wrote: post #63

Earlier quoted context omitted.

Do a take-home project but don't make them write from scratch. Give them a mostly working starter application. Sprinkle in some bugs. Start with easy spelling errors and go all the way to concurrency problems. Ask them to add a few simple features and fix any bugs they find. Bonus points if they find bugs you didn't add intentionally. Good unit tests are also a bonus. Give them a couple days or something. Don't count…

This sounds sadistic to me. I've spent a long time on dumb typos, which become a lot harder to spot when you are stressed and on a deadline. Chances are if you are applying for work, you are probably stressed about not having a job.

You've completely missed my point. It's not about being perfect. I want to work with people who leave code better than they found it but I can't expect perfection. I don't care if they can't find all the typos. I'm sure most software has typos.

Whiteboardimg a solution to n=np or building full applications is crazy and not realistic. Most interviews do that yet most work is fixing bugs and adding mundane features. Why can't interviews focus on the actual skills needed?

Re: Hiring Without Whiteboards

#407

Post by smabie » Wed, Jul 29, 2020, 5:27 PM UTC

fogetti wrote: post #310

smabie wrote: post #160

Is it simply a coincidence that people don't like whiteboard interviews and believe they don't work? Seems pretty convenient to me.

Conversely: Is it simply a coincidence that people like whiteboard interviews and believe they work? Seems pretty convenient to me.

I don't like whiteboard interviews and I don't know if they work.

Re: Hiring Without Whiteboards

#408

Post by azangru » Wed, Jul 29, 2020, 5:28 PM UTC

jnwatson wrote: post #399

azangru wrote: post #390

Earlier quoted context omitted.

- If the more desperate and less in-demand individual writes bad code, or makes poor judgements, you will be able to see it in their submission, won't you? - Whereas if such an individual, because of their desperation or lack of demand, has enough time and motivation to elegantly solve the problem, then what's not to like? I think a greater concern would be that with take-home assignments it's impossible to be sure y…

The programming test is just one aspect of a candidate, in my estimate about a third of the total "score". Take-home exams bias towards evaluating programming ability but bias against other desirable candidate qualities such as experience. Their desperation to get the job doesn't necessarily carry over to their day-to-day programming. If they take a month to do a week-long task, I would want to know. In terms of chea…

> but bias against other desirable candidate qualities such as experience

Won't you see, in the code submission, at least some evidence of experience? The way the candidate organises their code; the overall style; the third-party libraries they choose to use (or not to use); the tests they write (or don't write) — doesn't it all, combined, speak of experience or of lack thereof?

There are still other stages of the interview, where you can assess candidate's experience more directly, by asking about what they worked on.

I agree that it's useful to know when a task that should have taken x long takes 5x or 10x; but it may be because the candidate set a higher bar for themselves.

Re: Hiring Without Whiteboards

#409

Post by bananaface » Wed, Jul 29, 2020, 5:28 PM UTC

twic wrote: post #398

bananaface wrote: post #351

Earlier quoted context omitted.

This seems kinda nuts to me. I don't think I would leave a stable position for a probationary position, or accept one if I had more stable offers. "It's ok, we probably won't use it" - uhh, what? No, that's what legal protection is for. Is it really that common? I'm sure many companies try to hoist this on propsective employees but I'm surprised people accept it.

In the UK, the "probably won't use it" kind of probation is standard. You accept it because you don't get any offers without it. It really is the case that companies rarely randomly fire people during probation, so employees are fine with it.

Can someone else from the UK verify this? Still seems crazy to me.

Edit: reading around it seems like they're standard, but have no legal weight regarding termination? I.e. you're entitled to 30 days pay regardless. This seems very weird on all sides.

Re: Hiring Without Whiteboards

#410

Post by twic » Wed, Jul 29, 2020, 5:32 PM UTC

Aqua_Geek wrote: post #163

leonidasv wrote: post #123

Earlier quoted context omitted.

I hate take-home projects more than I hate whiteboard interviews. I think the best approach would be giving the candidate a broken app and have they debug it live or in a take-home debug-and-fix or debug-and-improve exercise. Could also have some refactor assignment. Has any company tried something like this before?

Apple did this in one of the sessions last time I interviewed there. They handed me a project in Xcode that had a number of bugs with varying degrees of difficulty — some caused crashes, others were UI glitches, etc. The assignment was to identify the problems and fix them. If you have more than a couple years’ experience the issues were pretty straightforward. I really enjoyed this session, but I can see how it coul…

We used to do this at an old job. We were a consultancy which specialised in a particular e-commerce framework, and were hiring people with experience in it.

So we set up a small project using this framework, and mildly wrecked it. Made some really basic mistakes, made some more subtle mistakes, added a bunch of dead code, wrote good tests for some of the broken stuff, wrote broken tests for some of the good stuff, etc.

Candidates came in, and we asked them to add some simple feature to the app, which we warned them may be broken. We had someone sort-of-pair with them as they work, to watch what they do and keep them on the rails to an extent. We then evaluated whether what the candidate did was sensible: did they run the tests, did they pay attention to the failures, did they find and fix the mistakes, did they get distracted by the dead code, etc. Candidates didn't have to do everything perfectly, but there is plenty of scope to go really wrong. I remember one case where the very first thing the candidate did was delete all the tests. Thanks for coming in, we'll let you know!

The company did quite a lot of rescue missions, where we would pick up a project that another consultancy had started and failed to deliver, and get it live. This interview wasn't just a trick, it was testing everyday skills!