Live data from Hacker News

Hiring Without Whiteboards

github.com

301–310 of 471 posts

Re: Hiring Without Whiteboards

#301

Earlier quoted context omitted.

> One thing I've been wondering lately about take-home tasks is how everybody complains about time estimates, and yet here's a bunch of "small projects" which someone pretends to have very precisely estimated. When I interviewed people and gave them a take home assignment I was very confident in my estimate for one simple reason: I completed the tasks myself. We had 4 tasks for this for the 4 different types of jobs…

Good for you; not everybody does that :) If you don't mind me asking, how big were those tasks?

We gave the estimation as follows:

- Junior developers should be able to finish this within a work day (8 hours) - If you are already familiar with all technologies involved then it should take about 2 hours even with all optional tasks completed.

As an example our backend dev task was to parse a CSV file (supplied with the task) and provide 2 API endpoints (return format and url defined in the task) that access this data (free choice in language and libraries). The optional tasks for this was to include unittests and to use docker.

That really isn't much work. We did get some good feedback about this estimate both from junior developers and seniors after they were hired or rejected. Most seniors seem to complete this task in about 1.5h to 3h and juniors do seem to be able to complete this in about 6h.

Re: Hiring Without Whiteboards

#302

The advantage of leetcode is that you study once and then it applies for every job you interview for. Like democracy it's a horrible system except for all the others. Take home project? There goes 4-12 hours per company that gives you one and sometimes more. Companies have no incentive to cut it down or not give it to even marginal candidates so you'll get a lot more of them than full in-person interviews. Pair progr…

In the past we had some candidates complain about take-home problems. The primary complaint was that candidates weren't interested in dedicating 4-5 hours of their own time unless they felt that someone from the company was putting in an equal amount of their own time. Some candidates also had suspicions that we were trying to use them for free labor (Not true, we used the same toy problem for every candidate). One c…

> an on-site whiteboard style interview where they solved a subset of the problem in pair-programming fashion with us

Do you offer candidates a remote pair-programming interview?

E.g. screen-sharing session over Skype/Zoom?

Re: Hiring Without Whiteboards

#303
Man I've said it before, but I need to get the hell out of this industry. Its pointless to argue against the whole whiteboarding / leetcode process, it exists for a reason, but I'm quickly realizing everything about the industry, including the industry process is just incompatible with the way I work.

Re: Hiring Without Whiteboards

#304

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…

Arrangements like this are much harder in US because 1) by default there is no health insurance if you’re a contractor, and obtaining your own is incredibly expensive and 2) there are also pretty complex tax implications of being a contractor; there are many other factors as well. It also puts a candidate at a disadvantage, because looking for a job is heavily one-sided burden. On a personal level, as both (occasiona…

Well, terminating an employement is as well quite easy in US, regardless who initiates it - employer or employee.

Re: Hiring Without Whiteboards

#305

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?

I don't understand how take home interviews are being held up as a better solution. They have two major flaws: They lower the cost for the company to zero. So they can widen their pool, and take a chance on more candidates, with no extra cost incurred for them. If you take this to the extreme – every company asking every candidate to complete a take home – then the result is far worse for candidates. There is no feed…

> I can say "you shouldn't spend more than two hours on this" until I'm blue in the face, but candidates think they need to polish far beyond what is reasonable

I'm going totally nuts about this particular problem. I have written in as clear terms as possible that I really don't want the candidate to spend more than 2 hours, but I don't feel I am going to convince anybody - especially as this is a (mini)game programming test, and with games you can always add one or ten more things.

Re: Hiring Without Whiteboards

#306
Can someone explain to me why isn't it ever part of the discourse to talk about certifications?

Most of the software engineers are certified right from the start when they graduate in university. All these people hold a certification in their hand, namely their diploma which proves that they are actually deemed suitable to hold any software engineering job in the industry.

The whole hiring process could be replaced with a timely renewal of accreditation. Then anyone who passed accreditation could be deemed as passed the technical interview. And then case closed.

Re: Hiring Without Whiteboards

#307
post #236

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.

When I have limited amount of time even if it's more than enough I get stressed. When I'm on a job I have time to think about the problem, come up a rough solution in my head then start coding. If I have a hard limit I don't think that much because what if I don't have enough time to write it down? In the sort thinking phase I came up with a subpar architecture, but even if I have an extra half hour in the endI can't really change it or worst You cant finish it because I didn't think of an edge case.

Re: Hiring Without Whiteboards

#308

Can someone explain to me why isn't it ever part of the discourse to talk about certifications? Most of the software engineers are certified right from the start when they graduate in university. All these people hold a certification in their hand, namely their diploma which proves that they are actually deemed suitable to hold any software engineering job in the industry. The whole hiring process could be replaced w…

The best programmers i've worked with don't have degrees in computer science, or anything like that. Metallurgy, civil engineering, mathematics.

On the other hand, i've worked with plenty of people with CS degrees from respectable universities who were useless. A degree is not anything like a certificate, and universities simply aren't in the business of actually deeming anyone suitable to hold any software engineering job in the industry.

Even if you fixed this, so that somehow every competent programmer, and only competent programmers, had some certificate from a university, all it would do is let you hire graduate developers easily. It wouldn't let you sort the wheat from the chaff at senior level.

Re: Hiring Without Whiteboards

#309
post #289

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…

Something seems badly off to me with the phrase "candidates who stumped 40 year veterans with elegant code". I don't want code that stumps anyone. I want code that delights 40-year veterans, for sure. But the signal of genuine elegance is "oh, that's a lovely way to do it" much more often than it's "how the hell does this work?".

It was more of 'I didn't know the C language could do that'. The elegance was that what it did was obvious.

Re: Hiring Without Whiteboards

#310
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.
Post reply on HN