Hacker News Reader

Comment by mindcrime | Hacker News Reader

Wow, OK. I suppose this is fine for someone who doesn't actually want a job, or in those rare times when the hiring market favors candidates. But in most cases, the company will just move on to the next resume in the pile. Why bother with this kook when there's a line of people outside eager to have a shot.

The thing is, not all companies do this. And there a LOT of other companies besides Google and The Usual Suspects. Heck, there are a lot of companies that aren't "tech companies" but they still employ developers. And they are probably less likely to do the whole "grill you on Data Structures 101" thing than Google. It's something to consider...

View on HN

I'm at one such company. I'm one of a 4-person dev team in the marketing department of a major lawfirm. My interview consisted of a conversation with another developer about code, both my github/portfolio and how we see development in general.

I had an offer an hour later and this is a fantastic place to work.

I actively avoided places with broken processes and it paid off in spades.

Is the compensation competitive? I've gotten the general impression that sometimes hiring is more broken than other parts of the company, and that the more competitive positions can sometimes have more frustrating interviews.

Not really, but I also put in a sub-40 week and the only thing that matters is that I get my work done.

I'll make the Work-Life Balance > Compensation choice every time.

"Heck, there are a lot of companies that aren't "tech companies" but they still employ developers."

Exactly this! IMO these are some of the best types of jobs too. You generally have real problems to solve and can see the impact you are making in the business.

That's if the business lets you make an impact, since you'll probably be in a "cost center" etc...

Very much disagree. I'm in one of these kind of businesses and I pretty much work directly with the COO and have a lot of say in how we get things done.

Get in, figure out how things work and how you can be useful and then build a reputation of getting things done.

My same experience. I have worked in a few non tech/software companies. From my experience the non tech companies really appreciate what you are able to do for them if you go about it with their best interest in mind rather than what you want.

There is sometimes push back on implementing things partly because non tech doesn't always understand the benefit. But if you are good at explaining and showing how something will save them money by streamlining a process or make them money by reducing friction somewhere, you almost always get the green light.

My experience is the opposite - many in the company defer to you and your knowledge, whereas at many "tech only" shops there's always an endless debate to be had about language, database, etc. etc.

Yep this is my experience too.

My company, which is a tech company, pretty much does exactly what the author describes as his preferred process: "I strongly prefer code reviews and evaluation of my public code samples and am just not interested in discussing why manhole covers are round or in reliving college coursework from 15 years ago." It's one of the reasons I wanted to work for them, and I think this kind of approach has the potential to be a competitive advantage. It takes more time to evaluate a candidate (though not unreasonably more) but opens up a much wider field of people and—from what I can tell—selects for better fit.

At my company, we do 2 phone interviews, then we do a 4 hour on site paid coding interview where we ask the candidate to code real world problems on a real computer, with an OS/toolset list that we ask them to provide for us. We let them know explicitly what we're looking for (getting it working, getting it right or getting it fast, etc).

This is about as 'real world' as we can make it, and it's generally worked out well. It's still problematic since it requires a physical block of time, and that eliminates some candidates who are currently working, but it's the best we've found so far.

What we do is a "take home test" that's pretty open ended (depending on which role we're hiring for). We basically give the candidate the requirements and they have 48 hours to send us something. Currently for our data science roles, we give them some instructions regarding where to find a specific dataset, and basically say "use data science tools, visualization, etc., to tell a meaningful story about something in this data." We don't dictate language, libraries, or anything. So you can use R, Python, Scala, Octave, Fortran, or whatever floats your boat. Then what we look for are things like:

1. Is it documented well enough that we can deploy and run the code ourselves?

2. Is the code clean, well structured, documented, etc.?

3. Does it run with no errors?

4. Does the output do a reasonable job of satisfying the requirements?

It's pretty open ended, which is itself a mixed blessing. Some people will look at it as an opportunity to really show off and show what they can do, and "flex their muscles" so to speak. Others may be intimidated by the lack of more detailed requirements. It's not a perfect test, but it works pretty well for us.

The one other risk is that the candidate will use a language that nobody here is qualified to evaluate (like FORTRAN), but in practice that hasn't been an issue.

Reply on news.ycombinator.com