Hacker News Reader

Comment by apetresc | Hacker News Reader

Is there a single interview method on Earth that will satisfy HN? These are all arguments I've heard in the last few weeks on here:

- Whiteboard coding is too far removed from "real work", not effective at testing general aptitude, and is demeaning.

- Asking to see side projects presupposes an unhealthy amount of focus on work, discriminates against people with lives, and is demeaning.

- Asking for a custom piece of real-world code that matches the company's actual stack is exploitative, should be illegal, and is demeaning.

- Basing everything on answers to 'soft' questions about previous experience discriminates against people who aren't interested in showmanship, leads to too many suits and bros, and is demeaning.

What on Earth should we be doing, then? Everyone on Hacker News is so enlightened and skilled at their job, that any form of verification is demeaning and beneath their dignity. Apparently I should make my hiring decision based on their comment history or something.

View on HN

I mean, I agree that HN find's it much easier to shit on interview methods than come up with something reasonable... But read the post. They're asking him to build a complete application, front and back, that does just what their app is supposed to do... Before he gets a phone interview. And then they offer 3 months uncompensated "onboarding" before ever paying for work.

There's bad interview practices, and then there's abuse.

> They're asking him to build a complete application, front and back, that does just what their app is supposed to do

Are we reading the same post? They want basically two API endpoints, one to receive a POST upload and another to return all the things that were uploaded. You could do this in Django (which they want you to use) in significantly less than 100 lines of code. It seems like an ideal little sandbox.

Even if that was reasonable, did you stop reading after the first sentence?

>...Authentication system that only allows authenticated users to upload photos but all users to view photos -Automated testing -Code coverage does not need to be complete, just generate that some critical functions of the system have tests attached to them. -Write-up on the systems design pattern choices

They are basically saying "make our entire product."

Yes, of course. Authentication is a single Django module, and they want unit tests (not even code coverage). Those are all scaffolding around the code that everyone agrees should be there. When people complain about whiteboard interviews, this is exactly the kind of stuff they argue is missing.

Bruh, they are asking for a well put together app with all the features you'd have in production. From an intern. You are right in that a senior dev could bang this out, but it would still take them a day at least. Interns generally don't know what they are doing. If they did they would be going for the higher paid job already. How does asking for an entire MVP from an intern ever make sense?

Even if they paid him to make this app it would stop being unethical but it would still be silly.

This isn't about the larger issues of interviewing methods.

This "company" is

1) Not a company at all, just 4 cocky and extremely naïve college students who think doing a 3 month internship at Amazon makes you "one of the leading React developers in the world."

2) is asking "interns" to build their entire product before they even consider "hiring" them

3) Has a weird idea what "hiring" means because they won't even bother to pay people they "hire" for 3 months because they think expecting a paycheck in return for labor is "toxic."

   What on Earth should we be doing, then?

You should accept that the process is going to cost you, and that there are going to be both false positives and false negatives.

Trial periods solve false positives, and you eat the cost of onboarding someone and their 1st 3 months or whatever. It sucks, but make the decision and move on. If you have this happen multiple times, your interview process isn't rigorous enough.

To improve false negatives you need a mix of inputs in your interview process. One way to get this is long/multistaged interview, but you will lose people this way too. Accept that if you are asking an interviewee to do real work (e.g. real world code) independently you should pay them for the time, and know that you'll lose some good candidates if you ask.

What does your post have to do with the OP?

The company in question is asking for someone to do actual work that they will use as part of the job interview, and then to work for free for 3 months, "non-negotiable".

You somehow think that is reasonable, and that anyone on HN who complains about it is simply whiny?

There have been a good number of posts on HN as of recent about hiring, interviewing, etc. Generally, the post lands, and many folks on HN come out of the woodwork to criticize the method or approach negatively.

The same happened with this post. (Of course I think in this case the behavior is exploitative and abusive. But do notice that not all folks in the thread disagree with the practice. Unfortunately they’re getting downvoted for disagreeing.)

You either didn't read the post, or you are taking their informal problem statement ("our frontend will call your endpoint [..]") WAY too literally. Hint: their frontend will NOT actually be calling your endpoint. They will probably never even run your endpoint once. It's just a way to describe where in the flow they want you to plug into.

They want an HTTP endpoint that takes a file over POST. Then they want an HTTP endpoint that returns the list of files over GET. They would also like basic things like a way to take an auth token to check if you have permission to upload, some unit testing, etc.

If you think this is anywhere even near to the ballpark of "actual work that they will use in their product", you're insane. This is basically 95% Django boilerplate that an experienced Django dev would be able to type out faster than it takes me to write this comment. To suggest that "write and read a .jpg" is somehow a part of their system that they're outsourcing (rather than the kind of thing you can find written out in dozens of Stack Overflow answers) is absurd.

I think it's a) really bizarre how invested you are in defending this obviously exploitative process -- do real work for us and then work for free for 3 months, sure, all the Django devs line up, it's easy game; and b) ridiculous the extent to which you are minimizing the requirements of the exercise. It's a code screen -- reasonable is making sure the candidate can write code, not that the candidate ships you a full stack functional product with a test suite and design pattern justification document. What is insane is trying to justify this with "its ok Django is basically magic lol". I don't think we have anything further to productively discuss.

I'm with apetresc, describing this as a "full stack functional product" is absurd if you really understand what's being asked for. The company and product might be stupid, and the unpaid offer shit, but as far as reasonable and effective ways to hire people goes asking someone to scaffold out a frameworked app and add a couple endpoints should be quick and is a great way to assess their judgement and attention to detail.

I don't know about apetresc but I'm vested in that being a good way to assess candidates, and think you're doing the world a disservice discouraging people from it just because you don't like the company/product/offer it's for.

Its for an _internship. At what point does anyone think a good test for someone who has years of experience doing the actual job, would be an equally good test for someone who is expected to have literally no experience? The only way that would make sense is if you are the type of company that advertises for entry level jobs with 7 years experience, which is to say that you are trying to get senior work for junior pay. In this case it looks like they took it a step further to senior work for no pay

>experienced Django dev

They are looking for an intern.

It sounds like you guys don't know what the intern market looks like. A significant percentage of students entering my University in first year have multiple significant side projects under their belt before the first day of class. We then all do 6 internships of 4 months at each company before graduation.

If a company in San Francisco wants an intern who knows how to build a POST endpoint, believe me, that is not an unrealistic ask.

Since I very frequently interview interns and was one myself (~15 years ago) I certainly know what the intern market looks like. Whereas it sounds like you're a college student, as you said "we do internships," not "we did internships."

Interns are not expected nor required to have any experience. You're being entirely unreasonable if you're looking for experienced interns.

If you're friends were so experienced already that they could land an entry level job by 18 then why did they go to college at all?

BTW, in the context of a job posting, "experience," means "professional experience," not "I threw together some shitty code one weekend in high school."

> ”Is there a single interview method on Earth that will satisfy HN?”

The simple answer is “no”. The HN community is not a monolithic block. You might as well ask if there’s one that would satisfy everyone. The key is to find one that works effectively for your organization.

Best interview I ever had was a $300 contract to add a feature to a company's API.

It was the only time I felt a fair exchange of time and money was tendered and I also felt that it adequately demonstrated my skills to the company and their codebase (and impression of future work) to me.

I didn't get the job but the company will always have my respect.

I agree, this is the right way to compensate for work that can potentially be used in production as a means of interviewing the candidate.

I faced something similar to the OP and posted the results on Workplace https://workplace.stackexchange.com/questions/88138/working-...

Making a candidate do actual company-related work during the interview process without compensation violates minimum wage laws in many states. It also could potentially violate IRS laws around employer obligations (tax disclosures, I-9, etc).

I don't see how objectively criticizing the above practice lands squarely in this ivory tower strawman you're invoking.

This presupposes there are actually issues with some of the aforementioned examples. The ultimate determiners of success are on the side of the company, not the applicant. A successful interview process is one that leads to a successful candidate, and really nothing else.

(N.B., The linked Reddit post is indicative of abuse, so I’m not talking about that.)

A lot of SW engineers complain after an interview process, especially a rejection, because of some “if only”-hypothetical. “If only they tested my real skills and not whiteboards. If only they saw that I’m a hard worker at work and I just don’t have time for side projects. If only they read my resume and know that I don’t need no stinkin’ coding test.” This is a strong aversion to false-negatives. But it generally seems to be in the company’s interest to over-reject according to some “stupid” rules than to over-hire.

I’m not saying that there are no wrong interview styles, but I think there is a supposition and sensitivity of a problem that isn’t being framed correctly—around applicant satisfaction and not company success. I think if more folks ended up being hiring managers, they’d understand the inherent difficulty in the construction of these supposed silver bullet interview styles.

(PS, I say this as someone who has complained very loudly and publicly about mistreatment at Google interviews.)

I think the more upsetting thing is the part where even if the candidate passes the "interview" and gets "hired" they must be trained (see: work) for three months w/o pay.

I wouldn't at all be surprised if all interns are let go after three months for a bogus reason ("you're toxic!") so that the company can continuously get free work from unwitting internship candidates.

What do you expect from a new hire? What kind of time to productivity curve do you have in mind?

I think all 4 forms of interviewing you are suggesting are reasonable and whether or not they are demeaning for the interviewee depends mostly on the attitudes of those involved. If the interviewer is a jerk setting out to dominate the interviewee, and does not even bother to conceal how they think the interview is going, it's going to be a demeaning experience. If the interviewer is polite, empathetic to the interviewee, and probes without hinting at the opinion they are forming, even a terrible candidate should be able to leave without feeling like they were unfairly treated.

You come in and hack with the team for a couple hours. You know, the activity that you'll be paid to do. How is this that hard?

You are saying that an engineer from my already resource-constrained team should be allocated to:

- make a quick onboarding of the candidate

- explain the general architecture of the system

- find an issue/story that is "superficial" enough to be taken by someone with zero-experience at that job, but "deep" enough that you can test their experience and knowledge (oh, and that story better not involve anything that might be related to core company IP.)

- do a pair-programming session with the candidate, and be the main driver ALL OF THE TIME (because the candidate does not have any git access, so their development environment is useless)

- evaluate the candidate

You really think that is something for "a couple hours"? Even if it were, do you think it is a good use of the time of the engineer that is going to be allocated to the task?

Never said it needs to be the current system. Make a simplified version if you want. Or something completely different that uses the similar languages/paradigms?

> Even if it were, do you think it is a good use of the time of the engineer that is going to be allocated to the task?

So what exactly is the alternative? Look, if you can't prioritize hiring, don't be surprised that you aren't able to hire. Yes, the engineers should be able to do this.

As an engineer that's been tasked to interview in this style, I have to say that it's possible to do with a few candidates without too much interruption to my regular duties, and it's actually my favorite method of interviewing. Having an inbound candidate build some simplified version of the thing we're making is extremely helpful and doesn't cost too much. You can easily define the simplified work sample project once and reuse it many times without spending too much time on it. The parent's criticisms are valid because there almost certainly won't be some work sample that fit all of the criteria mentioned and is actually a part of the product. But a work sample of a simplified version of the product they'll be working on is absolutely easy to do and insightful for both you and the candidate. Maybe they just really don't like the kind of thing you're working on. Well, this gives them a chance to dip their toe in the pool.

How many "systems" do you think your run-of-the-mill startup has?

What is the alternative? As most of things in life, the answer is "it depends". It depends on the size of the company, the type of candidate they are looking, the industry, and so on.

But let's assume we are talking about the average startup that is neither looking for superstar candidates nor only looking for fresh graduates from Stanford. For those cases, I believe that one simple programming task, that exercises some of the technology required can be used as a screening filter. The task should not take more than 2 hours to reach a working state. If the solution presented by the candidate is satisfactory, then you go to the interview to discuss the solution and how they got to the solution, the things that were easy/hard, and so on. Then you ask about the things that are missing, and the candidate's evaluation on how they would like to tackle.

Is that a satisfactory alternative?

I feel like we are talking past each other.

> How many "systems" do you think your run-of-the-mill startup has?

These dont need to be production systems, they can in fact be simple systems used just for interviewing.

So in your alternative, how long does an engineer really spend on interviewing the candidate?

In my alternative, the engineer needs to:

- Check out the code and review the solution.

- Give a pass or "call for interview".

Let's say that is half-hour of work.

Only for the candidates that get called-in, you can have an hour-long interview. Make it two hours if if you want. It will still save the interviewer time, and allow a better use of the time together.

A simplified version of this is what a whiteboard problem is. Me and a candidate work through some code for a small piece of a hypothetical system.

What if I already have a job?

How often can that really be productive?

You are right, we should do white board interviews mixed with "how many golf balls can you fit into a school bus". Now that's what I programming skill assessment.

Whatever it is, I think we can all agree that "Work unpaid for 3 months and then maybe have a job" is so far from the mark as to be laughable.

This is not HN being picky about interviews. This is a delusional company making absurd demands for which they are rightly being mocked.

Im currently interviewing (and looking for a job (resume link on profile)) and Ive gotten multiple approaches. Most time consuming one has been "do this test before we even talk to you on the phone". Which I get given all the phony devs out there. But it does get a bit tiring.

One thing Ive noticed is that asking for the hardest interview they have or can do usually gets them excited to talk with me. Which I like because there is nothing worse than a boring "reverde a linked list" type of interview.

There’s a difference between “shitty interview” and “predatory, unethincal (and possibly illegal depending on where they are) practices”.

There's a lot of complaining, but it's commonly held even outside of HN that tech interviewing is badly broken.

Its almost like it's a large community, with many different people having different opinions.

However, it does appear as if the community is pretty united on the idea that asking for free labor like this means you deserve to go get fucked.

It's not HN, It's just tech. I might offend folks but I don't care. I believe it's the new influx of over night programmers. Programming is now fashionable, pays well, everyone must learn to code. Take a class for 4 weeks and you are good to go. These folks then don't want to be subjected to the rigor of interviews. Then there's the set that have refused to keep up with the changes and believe that because they have been in the industry for a while and it worked out for them at one company they should get an easier pass.

This, absolutely. If I were looking to get my foot in the door, I would totally code a week for free. Hell, my first freelancing gig, I made 8$/hour.

The three months without pay thing...that's a little different. I'd tell them no way.

I think there's also a big difference in coding for a week for free for a qualified company and doing it for three college students, one of whom claims to be one of "the world's leading react developers" after a 3-month internship.

"If I were looking to get my foot in the door, I would totally code a week for free."

I absolutely would not. They're a company; they can afford to pay me. Me, however, my landlord isn't going to accept "I had to work for free" in lieu of rent.

making your hiring decision based on their comment history is not effective at testing operational development skills, and is demeaning.

> Asking to see side projects presupposes an unhealthy amount of focus on work, discriminates against people with lives

This argument is so ridiculous, because I enjoy programming it means I don't have a life? Is this an actual argument people make?

My takeaway is that it's more a mark against someone who doesn't want to do their job function in their non-working times as well. To me, not wanting to code outside of work if you're coding all day is perfectly reasonable and shouldn't count against you during an interview process, an expectation that you have side projects just feels unreasonable. There's obviously not gonna be anything wrong with someone who also likes to code their own projects outside of work for fun. That's my view from the outside as a non-dev, anyway.

That wasn't the argument though, the argument was it "discriminates against people with lives". That's an offensively wrong argument. If the argument was that it discriminates against people who don't hobby program, than yes I'd say that's correct.

There's some subtext you missed there.

"it discriminates against people with lives [outside of programming/tech/work]."

as in

"It should be ok, if you want to, to not spend all your time outside of work doing unpaid work."

Excluding candidates that don't have a github or whatever is a signal you are looking to get employees that you expect to spend their entire lives at work.

If hobbying programming is your strength, own it. Nobody is going to disregard code samples you send them. The context is employers requiring hobby programming.

i hacked on sideprojects when i had more time, but most of my sideprojects are automation things that i did when i had something to solve or help a friend, or some scrapping for my needs. the rest of my programming outside of work is freelancing. if somebody would ask me for sideprojects i would have nothing of value to show.

Yes, this was the overwhelming sentiment from a post that was on the front page just yesterday.

When you have a family and full time job it could be that you simply don't find the time for side projects even if you love programming.

That's fine, but the argument was that it "discriminates against people with lives". That's offensively wrong, as you're saying I don't have a life because I enjoy to program.

Reply on news.ycombinator.com