Hacker News Reader

Just so you know, in the past I used to actually bother to jump through the hoops like a trained circus performer for the apparent gift of employment from some place that actually needed me a lot more than I needed them. Then I would get all the way to the end of the interview and then tell them I would never take the position because of it. I used to hope this might stop the silliness.

Then I just stopped taking interviews with that nonsense altogether and found places to work that I actually wanted to be and that, more importantly, had mutual respect for one another as opposed to being treated like someone who was supposed to be grateful for working at some run of the mill office job. One where we were all supposed to pretend we were given some great gift of fixing someones crappy log file code that broke production. Or adding some api endpoints for a new model.

These jobs aren't all that great and all this nonsense is I'm sure keeping a lot of capable people out of the industry making slightly less money while being treated like human beings and equals.

I don't understand how asking you to write some pseudo code on a whiteboard is "(not) treating you like a human being". Honestly, if you're so willing to waste both of our time just to make some silly point then I wouldn't want to work with you to begin with. Extremely childish behavior.

I for one actually appreciate coding interviews. Besides, I know my resume isn't a bunch of stuff I made up yesterday, but how are you supposed to know that? I do wish most were done differently though.

A few months ago, I interviewed with a company--the first rounds were remote, and we used an online tool so the interviewer could watch me work problems in an environment with a "compile and run" button, which was great!

Imagine my disappointment, then, when I got to the in-person interview, sat down in a nice conference room with a computer attached to a giant TV and a wireless keyboard, and was handed a pencil and a pad of paper on which to code.

That's clearly something I need more practice with--but why? It's yet another thing I have to be good at to get work, that doesn't make me better at doing the work I get.

I did a 2 week stint like this for a small company once, and the setup took maybe 10 minutes.

In a bigger organization it's probably more involved, but if you set out to make it a standard way you interview some developers, I think it's perfectly doable.

I agree that improvising it when a developer asks for it, which is what I think you're describing, would be harder.

My first development job worked like that--a one-month trial that got turned permanent something like 2 weeks in, at a tiny company hiring at a slow rate.

I'm glad it got me my first gig, but I'm not sure I recommend it. IME, any position that actually gets applicants gets a flood of hopelessly unqualified candidates. (Think: will fail FizzBuzz, even almost a decade after the blog post that started it.)

Yeah, I think it's for unusual people in unusual situations.

My first dev job was like this as well, also in a tiny company hiring at a slow rate (I was the only person hired in my time there, and also the only employee). I think that this sort of thing worked for the company I was employed at because the work wasn't very technically challenging so I was able to get on with things quickly and it became more about cultural fit.

It's interesting that the parent is suggesting this for when you have a lot of experience rather than when you have none.

Given the number of people I've interviewed over the years who have 10 years experience and look very strong on their CV, but still struggle with our basic "coding challenge" (on par with FizzBuzz but more aligned with what our company was doing), even before we get to the real interviewing (with another alarmingly high dropout at this point as well), I can't see hiring for a trial being an effective strategy. We would be sinking way too much cost and effort in to it.

It may also result in poor hiring choices because one person's ticket/feature/whatever may have hidden challenges, and another person's might be easier than initially assumed. There's now more randomness involved in what's an already too random process.

Maybe interviews should be a bit less involved, and companies should be more willing to take advantage of the probation period (and employees too, I've seen a handful pass their probation and regret it).

The fact that you need to involve three different departments just to hire someone for a week is a key part of why hiring is so broken these days.

How so? HR needs to be in the loop unless I want to take on payroll, contracts, etc. IT needs to be in the loop unless I want to spend my time setting up equipment, which certainly isn't the best use of it. I am most valuable when I am leading my team and doing engineering. Not every company is some five man outfit, and successful five man outfits have to grow up at some point. There are many things to consider when bringing someone on, even a contractor.

Some companies have trade secrets. Do you think Google is really going to let you come in and poke at the Search stack for a week just to see if you're hireable?

This isn't about the number of departments. This is about companies needing to make very real tradeoffs between maintaining their current speed/security/stability and investigating future talent.

I'm a contractor with a decade's worth of experience, I automatically turn down places that ask me to do implement a linked list on a whiteboard, I do appreciate tests where I get an IDE and have to solve a simple problem, because after a certain level it's mainly about how you solve problems and how well you can explain what you are doing.

Can it be any IDE?

>Except now I have to jump through hoops with HR (let's just assume they'd be OK with this, which they almost certainly won't), get the contract in place, work with IT to get your environment set up, and bring you up to speed (so really I may get one full day of actual work)... just to realize that I don't want to hire you.

There are two major reveals in that sentence. One, HR rules your hiring practice and therefore you and your department, and you just advise them. Two, your company is so soul-suckingly bureaucratic, I couldn't imagine a good, creative, problem solving developer would ever want to work there. Both are red flags.

>Both are red flags

No they're not; they describe 98% (made up number) of the industry, and I don't think that "soul-suckingly bureaucracy" is an inevitable outcome of implementing reasonable processes.

We have IP that we have to protect. We have a company to protect (hence the HR involvement). Sure, you may be lucky enough to wing it in your little five man operation and get by, but you had better hope you don't run into a problem employee if you're not covering your ass. The sort of company you describe can be a ton of fun to work at, but you're also probably failing in a ton of areas and you don't even realize it yet. It's a mistake to think that your hipster SV perspective is the way that the world should work.

You are close minded. Instead of insulting people who dare to criticize your silly interview, maybe you should listen to them. Another red flag. You seem to think you are in a buyer's market. What does your company offer that is so compelling someone would put up with that silliness? Let me guess, market rates. I hope you at least inform applicants that you expect them to code on a whiteboard so you aren't wasting their time.

I think kayman talking about interviewing to work as an independent contractor because he said: "I have cultivated my own clients, ...".

Yes. I mean instead of asking me to do work for free. Why not I provide a small paid sample of my work. A risk both of us can take and live with.

If you don't like the work, we can part ways knowing we are not the right fit.