6 ms·

I've been involved in hiring senior engineers for a while now, and here's a few counterpoints: 1) Ruby is hard to get a job in, so you are off to a rough start

by larrik 9y ago

I've been involved in hiring senior engineers for a while now, and here's a few counterpoints: 1) Ruby is hard to get a job in, so you are off to a rough start. 2) A lot of people with lots of experience actually can't code for crap. Do you know how many python developers I see that don't know the difference between a tuple and list? Like, how could you be a real dev if you never even wondered why sometimes you use [] and sometimes you use ()? 3) These tests and interviews aren't intended for you to get some certain score. Usually we make them way hard to find out what you do to handle that. 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. 5) Every company's process is different because every company is different. Heck, my process is often different per applicant.

lifeisstillgood 9y ago
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?
- larrik 9y ago
  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.
  - lifeisstillgood 9y ago
    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.
  - collyw 9y ago
    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.
- Beltiras 9y ago
  Haskell rather than Erlang.
- fuzzygroup 9y ago
  Oh wow that's really, really good -- turn recruiting into fix bugs in an OSS project. Nice! That's good for everyone.
caioariede 9y ago
> 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.
haskellandchill 9y ago
> 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.
- Jedi72 9y ago
  Startups that once would be be Ruby shops are moving to Elixir in droves
  - eropple 9y ago
    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?
- busterarm 9y ago
  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...
busterarm 9y ago
> 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).
matchagaucho 9y ago
"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.
mixmastamyk 9y ago
3) If you don’t ace the coding test under the gun, you won’t proceed, with 100% certainty in my experience.
noahc 9y ago
> Ruby is hard to get a job in, so you are off to a rough start. Why do you say this?
iamcasen 9y ago
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.
- fernandotakai 9y ago
  > 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?
  - iamcasen 9y ago
    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.
    - tonyarkles 9y ago
      > 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)
emodendroket 9y ago
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.

by larrik 9y ago

lifeisstillgood 9y ago

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?

larrik 9y ago
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.
- lifeisstillgood 9y ago
  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.
- collyw 9y ago
  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.
Beltiras 9y ago
Haskell rather than Erlang.
fuzzygroup 9y ago
Oh wow that's really, really good -- turn recruiting into fix bugs in an OSS project. Nice! That's good for everyone.

caioariede 9y ago

> 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.

haskellandchill 9y ago

> 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.

Jedi72 9y ago
Startups that once would be be Ruby shops are moving to Elixir in droves
- eropple 9y ago
  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?
busterarm 9y ago
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...

busterarm 9y ago

> 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).

matchagaucho 9y ago

"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.

mixmastamyk 9y ago

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

noahc 9y ago

> Ruby is hard to get a job in, so you are off to a rough start. Why do you say this?

iamcasen 9y ago

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.

fernandotakai 9y ago
> 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?
- iamcasen 9y ago
  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.
  - tonyarkles 9y ago
    > 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)

emodendroket 9y ago

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.