Hacker News Reader

I think the main point from a candidate perspective is that long, unusual or difficult interview processes are fine as long as we have already decided we really want to work for you (that is you are Trello or SpaceX or some amazing startup we love)

otherwise, just as you are faced with picking a rose from a faceless mass of candidates so are we faced with picking a decent place to work from a faceless mass of mission statements and "100%code coverage" blog posts (if we can find any)

And 2) yes I can believe it - that's what fizzbuzz and its ilk are for. The number of companies offering hackerrank/codility tests and justifying it as we only hire the very best has left the lake woebegone test way behind.

There has to be some middle ground - where someone can pass a basic capability test to weed out the crap without demanding several hours of coding. I mean I spent two evenings recently polishing up a "Oyster card system for TFL" as a hurdle for a government department I have been angling to get in for a year. A no-name corporations wanting CRUD development can take a running jump if it thinks my evenings come cheap.

(amazingly at the turn of the century I used to use "has listed Python on CV" as a marker of "worth an interview" - it was rare enough and indicated an interest outside of corporate mainstream. Maybe Erlang today??)

Edit:

So my compromise suggestion is for companies to say "We have an OSS project (or even recommend one of the bigger ones). Take any of these 5 bugs and supply a pull-request"

At least then the evenings work is not totally wasted and you get to see an important skill - how fast can they come up to speed on an unfamiliar codebase?

We actually only do 2 interviews total, and for some roles a Hackerrank quiz.

The only times we use coding tests, we use Hackerrank to administer them. That way you have a distinct time limit (we give an hour, which is honestly way too long) so you don't spend all weekend one something that doesn't matter.

I definitely agree about the difficulty of picking a place to work. We reserve half of our final interview (and part of our initial interview) to be a Q&A for the candidate to interview us.

I think that Hackerrank etc are optimising for the wrong question. 98% of the time as a hiring manager I am not looking for a AAA coder - I am looking for an A level coder who fits the team and has other soft skills that matter.

At a certain point "can code" stops being "can write perfromant algorithms" and starts being "can work without direction, can be placed in front of users without fear, can defend their decisions, is not an asshat."

Ten minutes on a shared screen and we can find out if you pass fizzbuzz, can make a rational stab at an algorithm question. After that it's mostly cultural fit.

You cannot automate a test for "is not an asshat" so we get more and more people proving they can get 99% on programming tests when programming tests are 5% of the job.

Hackerrank is terrible as well. The questions are worded in a way that takes ages to think about unless you are a mathematician. The time limit is pointless.It doesn't tell you why things are failing. For the type of problems it gives you a debugger would be really useful but you are coding in a web browser.

Haskell rather than Erlang.

Oh wow that's really, really good -- turn recruiting into fix bugs in an OSS project. Nice! That's good for everyone.

The trouble with using bugs is that most of the work for fixing them is in isolating just what's going on and where the problem is, and there's no telling how long that will take until you do it. A bug on a new codebase could be anywhere from a few minutes to a few months.

In particular, if you don't know the codebase, you're going to be guessing on places to look. If you're lucky and guess right, you may spot it right away. If you guess wrong, you could spend a lot of time diving around irrelevant details. There is some skill in guessing well and not spending too much time on things that don't give any progress, but there's still a lot of luck too. Because of all that, it doesn't seem like a good idea to assign a bug that you haven't already essentially fixed.

Maybe it'd work to just timebox the task, i.e. 'work on one bug for an hour', along with 'document everything you find and learn' (and add it to the public issue). I'm a habitual documenter and I could imagine something like those 'papertrails' being a useful way to evaluate someone's thought processes (and written communication skills).

> 1) Ruby is hard to get a job in, so you are off to a rough start.

Huh? Enterprise level companies are desperate for Ruby engineers to maintain large Rails apps and there still is a good amount of startups doing new work with it.

Startups that once would be be Ruby shops are moving to Elixir in droves

My experience is that that's not true. A good part of my business is knowing the startup scene in general and Boston specifically; locally, I'm aware of...well, one company founded in the last five years that used Erlang or Elixir when the alternative was Ruby. (I'm only aware of three overall that use Erlang or Elixir at all. And that's kind of a shame because I really like Elixir.)

What substantive evidence do you have of this shift?

I'm a "Ruby engineer" but tend to avoid Rails teams because most of those large Rails apps are a giant pile of technical debt. They're looking to hire senior talent to clean up the mess but aren't willing to make the organizational commitments needed to make that effort succeed.

No thanks.

Edit: My 'favorite' experience was the few months of consulting work I did with a team building Rails apps to deal with medical records and the app that I came into had tons of dead code paths that leaked HIPAA-regulated data all over the place.

None of the API routes were 100% functional, so I spent my first few weeks cleaning that up and making it bulletproof. Then I fixed their broken homebrewed SAML IdP. None of that work that I did was appreciated as they only wanted (but wouldn't say that they wanted) new frontend features to show off to the client to inflate the quality of their work.

More importantly, they were using Rails4, but implemented everything by watching a Rails2-era Railscast and would get frustrated with me for not doing the same, a.k.a "the rails way" (I was, just modern Rails and not their broken bullshit). And that was the CTO...

> They're looking to hire senior talent to clean up the mess but aren't willing to make the organizational commitments needed to make that effort succeed.

Very well said and it happens in lots of areas where companies seem to wish for "big outcomes but all for free".

You will see this in security all the time.

"We have to make sure this thing is bullet proof."

"Ok it's going to take a month to harden and audit our the network and infrastructure and add monitoring and we'll be in good shape."

"Uhh ... no we didn't quite mean it like that ... can't you like install a plugin in half an hour that does the same thing?"

(made up conversation but you get the point)

> They're looking to hire senior talent to clean up the mess but aren't willing to make the organizational commitments needed to make that effort succeed.

Well yeah, churn and burn is my company's motto. At least we pay well.

I'm in the midst of maintaining/fixing one of those and I find it a great opportunity if you A) want to learn outside your comfort zone, B) enjoy figuring out problems that aren't just technical (talking to people, design, organization), C) want to get out of a coding-grind lifestyle.

Our organizational structure isn't immutable, it just moves slowly. After about a year, my team's effort resulted in measurable improvements for both revenue and end-user experience.

If you're senior dev level and want more of a challenge that's not just throwing more code at the wall, these sorts of scenarios are something to seek out.

Sometimes. I'm actually fully on board with what you said, but the situations I found and was describing are usually environments where they just expect someone to put their head down and code.

When I say "not willing to make organizational commitments..." I specifically mean they don't give you access to people -- stakeholders don't want to be bothered by the devs. It's far too common.

What you're describing though is a great situation -- I love those engagements.

That sounds really fun. I've done greenfield Rails projects and I've learned that what I really like and find rewarding is this kind of slow reorganization of something that already exists. It's like remodeling a house--maybe it was well built initially (and maybe not!), but you get to spend a lot of time inside of someone else's mind. You know, when they had good days and things just clicked, when shit was on fire and they just had to make it work. The results of seeing meaningful improvements to something like that is just fantastic, to the point where you're now excited to add on to the codebase.

I think part of the problem is that the author seems to ONLY be a ruby dev, rather than a polyglot, able to use the right tool for the job.

Point number 2 doesn't really land for me. I can see how a dev of 10 years might never have needed to think about tuples, depending on what code she was responsible for. Some folks aren't really curious about deep internals, they care more about the bigger picture. Scalability, system maintainability, ease of deployment, monitoring, ease of iteration, etc. If pressed, they can dig in and understand the internals, but that might not be what they are interested in/ care about.

> Point number 2 doesn't really land for me. I can see how a dev of 10 years might never have needed to think about tuples, depending on what code she was responsible for.

i'm sorry but i don't agree there. in this specific case, tuples and lists are really different and there's specific reasoning for using one or the other. it's a core feature for the language. it would be like saying someone that is a Java dev and doesn't know the difference between an ArrayList or a LinkedList.

i understand not knowing nuances of the language (in python, understanding how __slots__ work and how to make usage of it), but not knowing a core feature?

Perhaps I come from a different land, but in my field, knowing a specific language intimately is not as important as knowing the wider scope of software engineering and distributed system design.

I'm not a developer who is down in the weeds optimizing specific algorithms though, and I can see how a mastery of language-specific data structures and how they are represented in memory might be required for such a person.

> I'm not a developer who is down in the weeds optimizing specific algorithms though, and I can see how a mastery of language-specific data structures and how they are represented in memory might be required for such a person.

I say this after having done an M.Sc. in Distributed Systems focused on performance analysis. In a lot of cases that I've encountered, mastery of data structures and choosing languages and runtimes appropriately can completely eliminate the need for a distributed system, or significantly reduce the complexity (an efficient 3-node system is much less complex to manage than a 100-node inefficient system).

A recent example that comes to mind is a pair of similar systems, one written in Java and one written in Go. There was an approximately 80x larger memory footprint for the Java system while having similar functionality. Plus the Java system took about 2 minutes to start up (yay Spring), vs. sub-second startup for the Go binary.

I fully appreciate the high level design of systems, and these days that's what I spend a lot of my time doing, but when shit hits the fan and the implementation of the system doesn't perform the way I'd expect it to, it's time to roll up my sleeves and get down in the weeds to help solve whatever is keeping the system from reaching its full potential. Maybe that means there was a flaw in the design, but often it's just a shoddy implementation (with Pareto 80/20 fixes to make it better)

Absolutely! But you if you're interviewing, and you haven't been in the weeds lately, I think it's unreasonable to get passed up for a job because you don't know the nuances of some language specific feature.

Some folks are curious and have learned about deep internals, but after 10 years of actually producing production code and never using them, expecting them to pull it out in a 35 minute "technical" interview is the problem.

If your company hires based on a technical interview that everyone says is not representative of the work that is done, you are not hiring right.

"1) Ruby is hard to get a job in, so you are off to a rough start."

I get there is demand to maintain Ruby/Rails apps today... but how many are hiring for new RoR projects?

Seems there was a bout of "RoR and ActiveRecord Don't Scale" articles a few years ago... then suddenly the new cool frameworks became Angular and React.

Despite explicitly telling people I don't want to work in Ruby again I still get people e-mailing me about Ruby jobs. I think I need to switch places with somebody.

> 4) That said, you should know how to write code that isn't super slow and with a data model that isn't insane. You should also know how to articulate that, since as a Senior dev, you WILL be mentoring junior devs, and communication is not optional.

I agree, but this should be a clear point. You shouldn't be overengineering something unless you really have to.

3) If you don’t ace the coding test under the gun, you won’t proceed, with 100% certainty in my experience.

> and communication is not optional.

It's weird how prevalent the idea that communication _is_ optional in this industry. Headphones-on, heads-down engineering teams are to be avoided (by me).

> Ruby is hard to get a job in, so you are off to a rough start.

Why do you say this?