Hacker News Reader

Comment by twblalock | Hacker News Reader

Every time this comes up on HN we see why the problem is so hard to solve:

- Nobody likes whiteboarding

- Take-home assignments are unpaid work, and candidates who are raising children don't have time to do homework after they get home from work

- Pair programming during interviews makes people uncomfortable because of the pace or because it's not how they are used to working

- People who currently have good jobs are unwilling to consider contract-to-hire or "tryout" periods

- Credentials, including graduate degrees, are no guarantee that someone is a good engineer

The current interviewing situation in the industry sucks but all of the alternatives are worse in important ways.

View on HN

Nobody likes whiteboarding

Honestly, I really like whiteboarding. I liked doing programming contests too, which are like whiteboarding except harder and you spend more time at them. There are times when I have gotten together with other like-minded software engineers and given each other whiteboard programming problems for fun. (Also to test whether problems are good interview problems.)

A lot of people like whiteboarding problems and like interviewing with whiteboarding problems. Those are usually also the people who pass whiteboarding interviews. Just because there are a lot of complaints about them, don't assume that represents everyone.

I like whiteboarding too. It's stupid to expect people to write syntactically correct code on a whiteboard, but totally reasonably to use it to discuss a problem. I mean, that's why we have whiteboards in our offices in the first place, right?

People who participated in ACM competitions is my (now no longer secret) secret weapon when forced to filter thousands of resumes.

It’s probably the most strongly correlated with liking and being able to do the job signal I’ve ever seen.

Would you say the same about Google CodeJam? Some people didn’t have the chance to go to college...

Probably not, no.

First, you’re not going to get your resume in front of me without a college degree, CS degree or equivalent experience is a bar that recruiters apply well before I’m involved.

But as far as I can tell, Google CodeJam is an individual sport (I may be mistaken about that, but Google’s page won’t load in my browser, so I could only read the Wikipedia page about it).

The key thing about the ACM contest is it requires BOTH effective cooperation with a teammate AND the desire to solve programming puzzles.

Now, just to be clear, I’ve fired people who passed this bar; being a smart puzzle solver who’s social enough to collaborate is a great start, but it turns out lots of people just aren’t interested in shipping software. I still think ACM team participation is a strong signal, it just doesn’t cover the fact that being an adult means 90% of every job is boring, and not everyone is ready to do the boring stuff when they’re fresh out of college.

That’s interesting info, thanks.

Discussions about this in HN in 2015 [0].

[0] -- https://news.ycombinator.com/item?id=9324209

Candidates should just be given a horrible, undocumented, broken piece of legacy code and asked to fix it. Select the person who comes up with the quickest solution. That's who you want on your team when you find out there's a production issue at 4:30pm on a Friday afternoon.

I would love this kind of interview. This basically describes my job.

I'm OK with whiteboarding. I don't object to take-home assignments in principal, but I do object to them in practice -- they take up way too much time, and then part of the time you get ghosted after submitting them.

I think the right answer here, to the extent that there is a right answer, is to give applicants a choice.

It’s pretty hard to have a reliable interview process if you don’t ask all of the candidates to do the same thing. Comparing how a candidate performed compared to other candidates on the same set of tasks is an important part of the evaluation.

Consistent processes are also important for avoiding bias. For example, take-home projects are more likely to make sense for young candidates who aren’t raising families and have free time after work. If you have most of your young candidates doing take-home projects and the older candidates doing whiteboarding, you will end up evaluating candidates differently based on age.

Candidates have different strengths and weaknesses. Sure, I'll ask the base questions but in terms of assessing their coding ability I'll go with whatever they feel the most comfortable with.

If they have github, I'll ask them to walk me through a few files, asking their reasons for doing X, why not Y - what does this do?

If they prefer take-home, I'll give them something to create/improve.

Want to do something now? knock yourself out - with or without me watching.

I don't need to sort the candidate into an ordered list, just filter out the "over confident".

The questions I want answering is: Can they actually code? Does their skill match their experience? Is their skill level similar to the codebase?

The only time I've ever told a recruiter off was when I was asked to "spend about a half an hour to write a solution for [problem]" for Microsoft and it turned out to take about that long for me to set Visual Studio up on my laptop at home, and then an equal amount of time to figure out how to navigate the project files, etc. etc. and I could see that the interviewer A) had not given this any thought and B) had no idea how long this would actually take for someone who doesn't develop software at home.

That was assuming you even had a Windows laptop to set VS on. I know a lot of people have to say no these days since they just have a MBP running OS X.

> I know a lot of people have to say no these days since they just have a MBP running OS X.

That's where the person who knows how to set up a VirtualBox VM running Windows and VS would have a large advantage; when they brought in the result, showing their MBP running VS in a virtualized manner, and explained what they had to do - that's a bit more of an impression than someone who says "they can't do it because MBP".

You can actually run Windows just fine on a mac using bootcamp. The big problem is just getting a legit Windows license, and then the hurdle is just a few hundred bucks (or whatever a non-OEM non-upgrade license costs these days).

Also, I'm nowhere near ops jobs, so I don't think those people interviewing me would care much about those kind of logistics (anyways, they wouldn't want to know the details). It wouldn't score any "points" beyond just getting the task done at all.

> for someone who doesn't develop software at home.

Are you saying in general - or just for Windows-based software (since you mentioned needing to set up Visual Studio)?

The latter I can understand; but the former makes me want to ask, "Who applies for an SWE position who doesn't write code at home?"

I've been an SWE professionally since 1991 when I was 18; I got my first computer in 1984, and have been "coding at home" ever since. I'm not saying "to be an SWE you need a similar experience" (I know that's untrue) - I'm just relating that I've been coding for a long time, and "at home" is very much a part of it.

Then again, I've heard of people who absolutely hated coding, but were extremely good at it (and I assume made good money doing it), but when they went home, they didn't even want to think about such a thing. Maybe you are similar in that regard?

I guess I am just curious and a bit fascinated by your comment...

I wonder how many surgeons do operations at home.

I'm someone who does it for 8-10 hours a day at their day job. My fiance works in a retail store. She doesn't come home and immediately start doing retail sales out of her house. Another friend is a teacher and she doesn't run a school out of her house.

Professional baseball players rest after games. They don't finish up and then immediately start practicing again. And soldiers and police get down-time.

Just because I'm doing something I enjoy and that I want to do, doesn't mean I should do it all of my waking hours. I'm not doing this to code, I'm doing this because my employer is paying me to build cool shit and I like doing that. I don't lift weights 24/7, I don't run 24/7, I don't hike 24/7, and I don't program 24/7.

Frankly your attitude is one of the reasons why we don't have any diversity in this profession at most self-described tech companies, and it also underlies a lot of the seeming ageism today. All of these self-described non-conformists expect everyone in the profession to conform to their attitude and it's sickening.

If we could just accept that not all companies should cater to everyone, and each can pick their methods that work for them (and if you don't like it as an applicant, go elsewhere), things would be a bit simpler.

When Im looking for a job, I make it pretty clear what Im ok and not ok with, which will dictate which companies Ill interview at or not. If we were in a dotcom crash it would be a different story, but right now its definitely something people can do.

Why do you think that the paid take-home task which is related to the job (i.e. not leetcode riddle) is worse compared to what you've listed?

Even small-mid size companies can see thousands of applicants for a single position. You cannot pay every one of them at market rates for even a day of work without an unlimited recruiting budget.

But if they are not solving riddles, those candidates could do (good or bad) _actual work_ for you. Why not reward them the same way?

The code you write for these take-home tests will be evaluated and thrown away. It isn't actually making its way into a product or feature the company releases.

Or you hope it is being thrown away and not put into production...

I'm sure it's being done in some cases (but then any shady thing you can think of is being done by at least one company out there). But it is definitely very far from the norm.

I wouldn't offer a take-home task to anyone who wasn't already on my short-list. When I recruited interns at job fairs there were plenty that were just passing resumes out to whomever would take them.

And how do you come up with this short list? That's the point of the exercise. The order is usually:

Resume review -> take home exercise -> phone interview -> onsite interview -> offer.

How significant is that take home? I immediately reject such requests of unpaid work if it takes more than 10-15 minutes.

If in your case, you demand allocating more time for that step, consider adding additional filter (requiring 10-15 mins) after the resume review. And then redirect [part of] resources (money) from the onsite part to pay for that take home task.

Another red flag I see in your process - asking for allocating time before even talking to a human being - that would be another reason for an immediate rejection. Consider moving your phone part before the take home task.

Every company that has given me a take home exercise gave me a phone screen first. I don't think your order is at all typical.

When there is something before the phone interview, it is a coding assessment; these are generally different from a take home assignment in that they are generally timed and automatically scored, e.g. you hit start and have two hours and then a computer scores you. With take home exercises, I've always had engineers at the company read my code and discuss it with me.

>When I recruited interns at job fairs there were plenty that were just passing resumes out to whomever would take them.

Isn't that the point of a resume? What am I missing?

I've never heard of a paid take-home interview task. Has anyone here actually done one?

I've done one with Figma. It was one of the most enjoyable interviews I've had.

I have to say that from all of those, the least annoying has been the pair programming.

But to be fair the problems were not too hard, the interview was set-up properly (problem files on place and a good code editor at hand, no tricks or gotchas)

And the worse of course is having to write fizzbuzz in a whiteboard, I just have to roll my eyes then

The real solution is to allow me create a portfolio of work, which would be a total of about 100 hours and then let me use that _everywhere_. I have easily spent 5k hours getting the degree, the 100 hours over the ears it took to do that isn't a big deal. We could even have some sort of offical stamp that "this guy can code".

Doing 10 hours of work to apply for every random "we make another business PHP/crud website" company is not worth it.

Your company isn't Google, don't interview like it is. I am not going to write custom code for you, but I am willing to flash my credentials.

The best interview experience I had was when I was asked to bring in my laptop with some code. I had a very unfinished side project, so I talked the guy through it, he asked questions then asked me to add a simple feature. It didn't take a huge investment of my time, its code that I am familiar with, so no nerves problems, no clever algorithmic stuff.

> Credentials, including graduate degrees

Some people even suggest that advanced degrees are an anti-indicator of ability:

http://blog.alinelerner.com/how-different-is-a-b-s-in-comput...

They are also indicators of over qualification; e.g. will that PhD from CMU really be that interested in working on your CRUD app, will they find the work fulfilling enough to hang around?

And mostly they aren't wrong.

"- Credentials, including graduate degrees, are no guarantee that someone is a good engineer"

Too true, I've started to recruit non-CS people and teaching them how to code. The state of CS education in the US is insanely inconsistent. But I'm lucky, I have lots of time to train people; most companies can't handle months of startup time.

Want to hire me? I’m a reasonably competent programmer already, pretty good designer. Most recently I wanted to familiarize myself with the basics of C++ so I wrote my own big integer library.

Maybe this is the triplebyte business play, you come up with your own credentialing and companies pay you to access a high-signal talent pool.

> Nobody likes whiteboarding

That's why companies should allow laptops.

> Take-home assignments are unpaid work

True, they could be optional. You may not get the job if you don't do it. Honestly, if you can't spend one or two hours on a take home assignment during a 7 day period, you certainly have different problems than applying at this company.

> Pair programming during interviews makes people uncomfortable

I agree, pair programming during an interview is mostly a no go. Not because of the issues you mentioned but because most interviewers are totally unqualified to do this properly (unfortunately, most interviewers are also unqualified in general to conduct interviews). It takes a lot of skill to conduct pair programming interviews and draw the correct conclusions.

> People who currently have good jobs are unwilling to consider contract-to-hire

In US, there is practically no difference between those three. You can be fired any day anyway. But yes, if you have a secure job that is good, the bar for switching is high, but so what? Why even switch? It's your choice then... Luxury problem!

> Credentials, including graduate degrees, are no guarantee that someone is a good engineer

I would go as far as saying your credentials and degrees are horrendously irrelevant in predicting your skills as an engineer. The only thing you might be able to conclude is that a GPA 4 M.I.T. graduate probably can pick up missing knowledge quickly, as opposed to a no degree dish washer who learned "how to code" in a 6 week bootcamp.

On that note I have experienced first hand, Berkeley and Georgia Tech CS majors, who were absolutely incompetent on the job and just had no idea what the hell they were doing, with little improvement in sight...

> Honestly, if you can't spend one or two hours on a take home assignment during a 7 day period, you certainly have different problems than applying at this company.

That's an extremely privileged thing to say. And what a terrible way to start out your working relationship. The very first thing you ask of me is to do unpaid work in my free time? IF you're willing to do that, how else will abuse me in the future?

Also, why should they spend time on your homework before they know if you're a company they would even want to work for?

I mostly agree, but attending any interview is also doing unpaid work in your free time, and often takes a comparable amount of time to the sort of take-home assignments used for recruiting.

I think the reason why take-home assignments tend to feel more unreasonable is the asymmetry. If I attend an interview, it's costing a pile of my time, but it's also costing a similar pile of time for multiple people at the company where I'm interviewing, which gives me some reason to think that my application's going to be considered seriously and therefore that the effort I'm putting in isn't going to be totally wasted.

Whereas a company can hand out a take-home assignment with no effort at all, so the fact that I've been given one doesn't indicate that the prospective employer sees me as a serious prospect or that there aren't hundreds of other candidates in the same position as me, so it's no guarantee that my chances of getting hired aren't miserably low, so there's more risk that I'm wasting my time.

I think you've hit the nail on the head here. A homework assignment does not indicate seriousness on the part of the company. Great insight!

As someone who uses take-home assignments as part of my hiring process, I disagree that it is no effort at all. We still have to review submissions, get the code running (we usually let the candidate do the problem with the tools of their choice). You won't believe the number of candidates we receive with great looking CVs who struggle with a warm-up coding question like this: https://www.hackerrank.com/challenges/python-quest-1/problem If anything, completing the assignment and at having some working code already gets you above 90% of applicants.

Would you feel better for it if you were paid $100 to do the assignment? That might be way less than you normally make, but it's something.

One of the sibling comments said it well. It's not the money, it's the fact that giving me take home work shows a lack of seriousness on the part of the company.

Although perhaps an escrow system would work. The company pays me a large sum (say $10,000), which I then pay back if they call me in for an interview. That way I know they are serious, and it actually forces them to consider the cost to themselves.

I might. Or I could do it at my normal short-term contracting rate and bill you the hours.

It's not perfect, but personally far preferable to having to perform with a gun to the head in an interview. Which has nothing in common with how software is written in the real world.

The start of your working relationship is really important. I'll get interview offers all the time and if the compensation is off by more than 3% I just tell them no, due to compensation. Usually I get a contact back asking what I was looking for and I just tell them that I am not in the market to be making my compensation an issue each time I want a raise. They had an idea what they wanted to pay and I am not who they are looking for.

You are already wasting more time on doing the interviews. Why a 3 hour home assignment is any different?

One of the sibling comments said it well. It's not the money, it's the fact that giving me take home work shows a lack of seriousness on the part of the company because my time investment is much greater than theirs.

I just can't understand this mentality. You are the one who wants the job, doing the bare minimum of effort to prove that you can perform the job is too much? Why should they review your code before they know if you're someone they'd want to work with? It's part of the mating dance, and it goes both ways. Presumably you would have read up on the company or spoken to people in the industry? Unless you have some other way of proving your ability (Github projects, Kaggle, research) don't expect a job to just land in your lap.

> credentials and degrees are horrendously irrelevant in predicting your skills as an engineer

I'd suggest that an MSEE or MSCS degree from a good school tends to be pretty good training for working in the industry. The projects you complete are usually challenging, relevant, and intentionally educational.

For example, an MSEE might learn how design analog amplifiers and filters, program a DSP, lay out VLSI circuits for an ASIC, implement a RISC CPU in verilog, implement an internet router on an FPGA, and implement Wi-Fi on a software radio. I'd be happy to hire (or work with) someone who can do all that!

Yeah except that for 99.9999% of software engineering jobs, that knowledge is irrelevant. Also, to be a good engineer, you need to have MUCH more than just some math and raw computer science knowledge. I would go as far as saying that all scientific tasks are mostly carried out by research scientists these days anyway. The skills you need at companies like Google or Amazon, as a regular engineer, have VERY little to do with what you learned at University, which is why we hire even PhDs as junior engineers, and they usually are. They know a lot of stuff that doesn't matter (like how to color a graph), sure, but they also don't know a lot of stuff that matters (how to build production quality software, without shooting yourself into the foot at every turn).

I really wish university CS programs would have a course on how to use source control (probably Git), and CI (probably Jenkins).

I'm sure some programs teach this stuff already. But I've hired people with graduate degrees in CS from well-known schools who didn't even use source control for their group projects in grad school -- they just emailed the source files to each other.

What a strange and puzzling response!

0. You seem to have misunderstood my electrical engineering example.

1. Why would an MSEE not qualify you to be hired as a junior electrical engineer?

2. Why would a PhD in the appropriate area not qualify you to be hired as a junior research scientist?

>> People who currently have good jobs are unwilling to consider contract-to-hire

> In US, there is practically no difference between those three. You can be fired any day anyway. But yes, if you have a secure job that is good, the bar for switching is high, but so what? Why even switch? It's your choice then... Luxury problem!

It seemed weird to me that we are one of the only industries (well I guess engineering in general) who gets a contract that is contingent on each day until it is completed. At any given point you could be let go and yet if I contract someone to work on my home to legal work you setup a contract that states you owe them the money unless you are willing to go to court to contest their work.

When I last did a contract-to-hire it was basically "you can be let go for any reason, from slow output to your boss having a headache." Unless you get a sweet deal its difficult to pull a job with a set start / end time with guaranteed payout regardless of employment. I busted my hump at that last job so instead of doing my 6 months for the hire option they offered me the job before then 2nd month was over.

Not only that, but the GP misses the point that, while yes I can work for myself and do contract work, I then also have to find health insurance, pay taxes monthly, do a bunch of extra accounting that does nothing to move my business forward and is boring, etc. That's fine if you get more benefit that the resource sink of doing those things, but for most people that's only additional stress and no additional value. So saying they're equivalent is patently absurd.

Yeah, maybe degree isnt a great indicator of a programmer's skill, what about their past experience and projects? I think that at would at least make someone more confident in their abilities.

Reply on news.ycombinator.com