More on Hiring Software Developers • Hacker News Board

Re: More on Hiring Software Developers

#21

Post by vonmoltke » Thu, Feb 13, 2014, 2:08 PM UTC

jheriko wrote: post #10

"I took me 2 hours to figure out how to parse the RSS feed, extract the data I need using regex (since it was all inside a single tag) and present it in a table view." i hate to be negative or damning in anyway - you make many valid points. however what you did there is an awful performance imo. i suspect it comes from living in web circles too much. i mean... you used a regex? this is one of the rare cases where i w…

> i hate to be negative or damning in anyway - you make many valid points. however what you did there is an awful performance imo. i suspect it comes from living in web circles too much. i mean... you used a regex? this is one of the rare cases where i would write a c program with old fashioned procedural logic and expect it to be done much faster and to a higher quality.

You were able to come to these conclusions with no knowledge of the content of the data stream, just assumptions?

> also yes, good programmers perform very well in unfamiliar environments.

I think your definition of "good programmer" is nearing unicorn territory.

> not having the api you want is a common real world problem - learning new apis on the fly is a vital developer skill. the idea of an unfamiliar api should neither be daunting or challenging - unless it is of exceptionally poor quality (poor naming, no docs, no samples you must reverse engineer everything - but that shouldn't stop you either).

By the sound of it, there was no API here. He was thrown a raw RSS feed and had to figure out what was in it and how to extract the relevant information.

> also, i hear a lot about the value of regexes - be careful, this is a web centric view. regexes are a very limited parsing/recognition tool and outside of web development - they go unused for most such problems - they either aren't powerful enough or add a needless layer of complexity in the general case.

NLP makes heavy use of regexes for tasks where GLR parsers are overkill or where we have to fix character encoding or other such data noise.

> good luck though. given more time and practice you will learn to eat these interviews up then spit them out with you rejecting them for making a poor first impression on you as a prospective employer... interviews work both ways after all.

Exactly what we need to do, teach to the test. That will keep interviews effective.

Re: More on Hiring Software Developers

#22

Post by vonmoltke » Thu, Feb 13, 2014, 2:12 PM UTC

johnnyfaehell wrote: post #13

invalidOrTaken wrote: post #11

Earlier quoted context omitted.

Fairly easily? If you're maintaining legacy code, here's what happens: you dive in, are horribly confused, and figure it out. Aaaaaaand...now you know it. Who cares if it took you three days to figure it out? You're going to be maintaining that codebase for a long time, aren't you? We're kidding ourselves if we believe that our dev work is "all-new algorithms, all the time." It's not.

Who cares? Stakeholders who are pissed of the legacy system isn't working and want it fixed now. If it's legacy and you're changing it, it's generally because it's broken and someone finally noticed.

In my experience, cases where the system needs to be fixed right now are fairly rare, and in those cases the task is usually delegated to the person with the most system experience anyway.

Re: More on Hiring Software Developers

#23

Post by kabdib » Thu, Feb 13, 2014, 2:38 PM UTC

thezoid wrote: post #15

ronilan wrote: post #12

It's like, really, totally, entirely, off-topic, but, like I heard, somewhere, that some companies, like might, may be using, sometime, the following puzzle in their hiring process: Imagine a world in which: 1. A players hire only A players; 2. B players hire C players; and C players hire D players etc. all the way down to Z players. Assume that: 1. The trickle-down effect from B to Z causes bozo explosions in compan…

A players should work on pulling people in other categories into their category. If everyone works on making everybody better you can make the place better. Rejecting people because they don't match your idea of an A player (I'm assuming 'perfection') is pretty narrow minded.

I agree, it's narrow-minded.

But it's SURVIVAL.

The times I've had to work with mis-hires have been awful, miserable and very depressing times. Like, they made me not want to come into work.

I was once the "human grep" for the mis-hire that sat across the hall from me. Constant questions; apologetic questions, but continual and unrelenting and stupid questions. Q: "Where does this function get called?" Me: "Search for it, please." Q: "What are the arguments to function X?" Me: "Please go find the function and see." Every few minutes, for MONTHS. Nothing I did seemed to help; this person was simply addicted to asking people about stuff that was literally in front of their face. Management didn't help ("this person is doing negative work"). Pleading didn't help. Getting them to save up questions for an "on the hour" chat didn't help. I wound up leaving that job.

Should we help people in a lower "letter grade"? Yes, if they are teachable. Should we suffer? No.

The simplest thing to do: Hire people better than you are, in general. Really try to do that and you'll find that your company won't rot from within, and people will be happier and tend not to leave.

Re: More on Hiring Software Developers

#24

Post by rcruzeiro » Thu, Feb 13, 2014, 2:39 PM UTC

thezoid wrote: post #15

ronilan wrote: post #12

It's like, really, totally, entirely, off-topic, but, like I heard, somewhere, that some companies, like might, may be using, sometime, the following puzzle in their hiring process: Imagine a world in which: 1. A players hire only A players; 2. B players hire C players; and C players hire D players etc. all the way down to Z players. Assume that: 1. The trickle-down effect from B to Z causes bozo explosions in compan…

A players should work on pulling people in other categories into their category. If everyone works on making everybody better you can make the place better. Rejecting people because they don't match your idea of an A player (I'm assuming 'perfection') is pretty narrow minded.

Well said. For me, what companies should look for is potential. No one can know everything and you can either hope to find someone who knows exactly what you need or find someone capable and willing to learn. How do you find someone with potential? Don't just give them a problem to solve but work with them in solving the problem. See how their thought process is and how well can they communicate their assumptions about the problem at hand. Nod them in the right direction sometimes and see how they take it from there.

Re: More on Hiring Software Developers

#25

Post by ap22213 » Thu, Feb 13, 2014, 2:56 PM UTC

ronilan wrote: post #12

It's like, really, totally, entirely, off-topic, but, like I heard, somewhere, that some companies, like might, may be using, sometime, the following puzzle in their hiring process: Imagine a world in which: 1. A players hire only A players; 2. B players hire C players; and C players hire D players etc. all the way down to Z players. Assume that: 1. The trickle-down effect from B to Z causes bozo explosions in compan…

You lost me on the computer vision algorithm part.

Re: More on Hiring Software Developers

#26

Post by tbrownaw » Thu, Feb 13, 2014, 3:00 PM UTC

kabdib wrote: post #23

thezoid wrote: post #15

Earlier quoted context omitted.

A players should work on pulling people in other categories into their category. If everyone works on making everybody better you can make the place better. Rejecting people because they don't match your idea of an A player (I'm assuming 'perfection') is pretty narrow minded.

I agree, it's narrow-minded. But it's SURVIVAL. The times I've had to work with mis-hires have been awful, miserable and very depressing times. Like, they made me not want to come into work. I was once the "human grep" for the mis-hire that sat across the hall from me. Constant questions; apologetic questions, but continual and unrelenting and stupid questions. Q: "Where does this function get called?" Me: "Search fo…

So the only possibilities are that someone is practically perfect in every way (A), or entirely incompetent (B-Z)?

Re: More on Hiring Software Developers

#27

Post by ronilan » Thu, Feb 13, 2014, 3:17 PM UTC

ap22213 wrote: post #25

ronilan wrote: post #12

It's like, really, totally, entirely, off-topic, but, like I heard, somewhere, that some companies, like might, may be using, sometime, the following puzzle in their hiring process: Imagine a world in which: 1. A players hire only A players; 2. B players hire C players; and C players hire D players etc. all the way down to Z players. Assume that: 1. The trickle-down effect from B to Z causes bozo explosions in compan…

You lost me on the computer vision algorithm part.

Use self.lookAlike(); It is a global method ;)

Re: More on Hiring Software Developers

#28

Post by thezoid » Thu, Feb 13, 2014, 3:20 PM UTC

ricardobeat wrote: post #18

thezoid wrote: post #16

Earlier quoted context omitted.

Let's throw you into a high stress environment give you data you've never worked with before and on top of that, just for funzies throw some namespaced SOAP at you. Oh and here's the WSDL, we want you to use that too, no parsing it on your own by hand. A lot of people don't parse XML as much anymore. Most API providers have moved over serving up JSON and pretty much ask developers to only use that API. Also this comp…

Reading a XML feed instead of JSON is not comparable in difficulty to your examples at all. Getting XML parsed is not rocket science, just use a library. That was probably not the hardest part of the problem. We have no idea where the expectation of working with their JSON API on the interview came from, the RSS feed could be their standard test problem. They didn't "fuck up", I'd even say their filter (reasonable or…

I'd say it depends. There's lots of things that can really throw people through a loop. Maybe you are using an editor they aren't familiar with, or perhaps you don't have your environment setup for gradle projects. There's so much more to this that we don't know. I'm willing to give the benefit of the doubt.

A way to get around excuses like these are to encourage people to bring in their own systems. Explain that you know how your setup might be awkward and it's probably better if they work on something they are familiar with. Besides, during the pairing session, you shouldn't be writing too much anyway.

Re: More on Hiring Software Developers

#29

Post by pistle » Thu, Feb 13, 2014, 3:22 PM UTC

tbrownaw wrote: post #26

kabdib wrote: post #23

Earlier quoted context omitted.

I agree, it's narrow-minded. But it's SURVIVAL. The times I've had to work with mis-hires have been awful, miserable and very depressing times. Like, they made me not want to come into work. I was once the "human grep" for the mis-hire that sat across the hall from me. Constant questions; apologetic questions, but continual and unrelenting and stupid questions. Q: "Where does this function get called?" Me: "Search fo…

So the only possibilities are that someone is practically perfect in every way (A), or entirely incompetent (B-Z)?

People can change at human timescales. Businesses die at business timescales. Business timescales in technology are shorter than human timescales. So, lower downs could become higher ups, but not by the ship date.

Re: More on Hiring Software Developers

#30

Post by scrabble » Thu, Feb 13, 2014, 3:27 PM UTC

jheriko wrote: post #10

"I took me 2 hours to figure out how to parse the RSS feed, extract the data I need using regex (since it was all inside a single tag) and present it in a table view." i hate to be negative or damning in anyway - you make many valid points. however what you did there is an awful performance imo. i suspect it comes from living in web circles too much. i mean... you used a regex? this is one of the rare cases where i w…

I had to do a pretty similar task in the interview process to land my current role. They provided me with an example of a poorly written program to parse the RSS feed.

Their example was using regex to parse. The first thing I did was rip it out. I think knowing when to use regex and when not to use it is a valuable skill.