Hacker News new | past | comments | ask | show | jobs | submit login

Please propose a better process!

> Google wants to waive their interview process as you are an open source contributor. Other companies beg you to work for them even if you don't consider them interesting, willing to overpay you and pamper you.

That's not a realistic scenario, your point seems contrived. Google doesn't waive their interview process, as the @mxcl example demonstrates. Companies only beg to throw money at you and overpay you if you're famous or have a niche skill. If that's true for you, this conversation is irrelevant to you.

> Now comes your unknown company/startup. In order to even talk, you require passing some HackerRank coding test.

As I said above, I'm assuming this process only starts when you express interest in the company. If you're complaining about having to respond to recruiter spam, I can't help you. Nobody is forcing you to take any tests. You should only do it when it's for a job you want.

> In the end I won't work for you. I won't consider anything you offer.

What you're doing is avoiding false positives by screening for something you care about. The same thing Google does. Except Google has statistics on how well their screens work.

> You wasted time and money on me.

Or, more accurately, they saved time and money by not doing lengthy and involved interviews or researching you heavily before discovering it's not a good fit.




> Google doesn't waive their interview process

They actually do. What they told me is that if you are an open source contributor for important open source, or you have 3 people within company that want you, you can skip the whole process. There are surely more ways to skip it. Not sure why they didn't do it for that Homebrew guy.

> when you express interest in the company.

I was mentioning that these days often HackerRank is step 0 of interviewing process, like what used to be technical phone screen. And that holds even for recruiting agencies if you want to have your CV featured there, even for underwhelming jobs. TopTal IIRC also does that.

> they saved time and money by not doing lengthy and involved interviews

I wouldn't be so sure here. You can be easily played, i.e. you are in Seattle, somebody wants to visit friends there, schedules an interview with you, you pay flights + hotels because you are happy to talk to them, they use you and extract whatever information they wanted to acquire from you and then tell you they decided for another alternative, but went there mostly to visit friends/relatives/handle some administrative business. It happens.

> Please propose a better process!

It's tricky. The deficiency in your approach I see is that you expect candidate to spend time in convincing you without you spending time on researching them, pushing all externalities to the candidate. With this you IMO cut the people you want/need the most as they usually value their time. Maybe if you offered compensated initial interviews to people you spent some time researching, that could help? That would be a signal you did your research already as you wouldn't want to waste money on random people, and that you appreciate them dedicating time talking to you?


> The deficiency in your approach I see is that you expect candidate to spend time in convincing you without you spending time on researching them, pushing all externalities to the candidate.

You expect people to do research, but you clearly haven't listened to anything I've said about my process, which I've commented on multiple times in this thread. Your summary is a straw man unrelated to anything I do when I hire people.

And you still haven't yet proposed anything better!


I think what you are looking for is confirmation bias. Can't help you and have to eject myself from this thread.


I'll bite on your suggestion of a different process.

Bring the candidate on site for a 4 hour coding session. Provide a standard list of questions the scale in difficulty. Think:

1) Fizzbuzz

2) Reverse a string

3) Write a calculator class/script

...

100) Write an algorithm that can search compressed text without decompressing it

So you see how far and correct they can get with an IDE ... and maybe no internet connection.

Noon - Hiring Manager lunch Afternoon - 1 or 2 design interviews on the white board.

So you have done a few things here that I want to outline.

A) You got rid of the stupid whiteboard

B) You have one process that scales for experience levels!

C) You can tailor the problem set at a certain of difficulty to specific languages

This interview style ensures the developer/engineer knows how to code, and can be weighted appropriately to certain skill levels.


>>and maybe no internet connection.

Even the top notch devs I know can't do anything meaningful without an internet connection. Unless of course you know how to invent several layers of libraries, instantly in hours without bugs. Know the documentation of the libraries memorized to the last full stop.

In my exposure at least I know 0 devs who can do this. And I'd bet even the interviewer wouldn't be able to write any meaningful without a network connection. This isn't 1960s. By very definition almost anything today requires an internet connection.


I love this suggestion, and thank you for elaborating! FWIW, the interviews that I've talked about taking as a candidate actually used this approach. And, when I give interviews, I use this approach too.

The only thing I'm really defending here is using a 2nd stage screening process that only takes 30 minutes, before I go to the 3rd stage that takes a half day or full day. @BitL seems to be fighting the screening process, which is a necessary practicality and isn't going away.

The first stage is reading resume and glancing briefly at any side projects, which is ~5 minutes. The first stage is invisible, and filters out more people than any other stage. If anything unfair is happening, it's happening here, and there's little a candidate can do about it.

My thoughts on your outline:

A - getting rid of the whiteboard is of course optional. In my case, having graded exercises doesn't mean I stop using the whiteboard. I only provide a whiteboard for people who want one, and I don't ask people to whiteboard things better done in an IDE.

B - Yes! I do like having exercises that range from super easy to not solvable. It helps to know where people get stuck.

C - Yes! That's very helpful for language specific jobs. Personally, I also like exercises that are language agnostic, to let the candidate pick the language they're most comfortable with. I've loved doing coding quizzes in Python during interviews, and would prefer that over, say, C++.


You do not know how many good candidates are filtered out because you have bad hiring practices.

I was tricked into a code golf challenge which was a hiring test. The result was good I was surprised that slacking off could get me a nice discussion, and the company got to pitch their positions. I've never done a hacker rank thingy for hiring and probably never will, I loathed them in school. They do not tickle my mind nor can I scratch my itches with them.

I know this sentiment is shared by many high value employers I've had the pleasure to work with.


> @BitL seems to be fighting the screening process, which is a necessary practicality and isn't going away.

Dunno. Google sent me flight tickets to Mountain View on-site interview without doing any phone screen. YMMV

Maybe sometimes you would consider skipping it as well? Maybe clicking through someone's resume could prompt you to skip that process? Maybe even onsite interview or making it just a friendly chat?


What I liked was using shared Jupyter Notebook during a video call. You avoid whiteboard coding, you can see what the algorithm does immediately and fix any issues and both interviewer and candidate can have more interesting conversation, telling you if you are a good personality fit.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: