More on Hiring Software Developers | Hacker News Reader

More on Hiring Software Developers

hesh.am

31 pointsHeshamMegid45 comments

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

2. Bozo explosions are bad.

3. No one knows what letter player they are.

Develop a computer vision algorithm to minimize the risk of a bozo explosion.

edit: puzzle concept source: https://www.goodreads.com/quotes/391717-steve-jobs-has-a-say...

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.

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.

Small project timescales are shorter than human timescales.

I've had my current job for 7 years. Most of our work in in SQL. When I started I went from knowing approximately nothing of SQL to being productive to helping other team members in a few months. This matches what I've heard in other places, that it can take 1-6 weeks to become minimally productive (as in, not a net loss to the team) in a new language and 6 months to become competent.

But, my employer is not a Startuplandia single-project exocompany. We haven't renamed "project manager" to "CEO" or "Director" to "Investor". We have an actual sustainable business model, rather than "exit or bust". We have people running the place, who have been around long enough to understand beyond the latest hype cycle.

No, but

- try to hire people who are better than you

- remember that people do grow; recognize potential, but don't assume that someone can be fixed

The sense that someone is merely adequate is a killer. When I'm on the fence about hiring someone, the correct answer is "No hire."

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.

> If everyone works on making everybody better you can make the place better.

I totally agree with this, but it requires active participation on everyone's part. It only works when people want to learn and actually want to produce high quality work. Many people don't seem to have any desire to improve their output. How do you fix a person's work ethic?

  How do you fix a person's work ethic?

I don't think you can, and the question is, is it possible to recognize the culture fit/misfit during the interview process.

I think you have a great point. But I would like to see a world where it happens the way you described it.

You lost me on the computer vision algorithm part.

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

I've heard this a lot. And usually the people espousing such hiring practices are C players when it comes to management.

While it sounds really good in theory, I think it's very difficult to discern an A player from a B player without letting biases get in the way (college attended, degree attained, GPA, etc).

Generally, I advise people to find what works for them, build a team that has consensus on hiring practices, and stick with it. But just because you found something that you think works, doesn't mean you've built a team of A players.

That will solve itself once all the B players retire.

So who hires the B players?

"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 would write a c program with old fashioned procedural logic and expect it to be done much faster and to a higher quality.

also yes, good programmers perform very well in unfamiliar environments. 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).

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.

as a concrete example most compiler generators will use regex for lexing but not for parsing at all - even repeated regex on a tokenised one line string is nowhere near as useful or practical as ll, lalr or especially glr parsing.

they also add a layer of complexity... someone famously said something like "oh, you used a regex... now you have /two/ problems"

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.

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 company fucked up. So you can't provide access to an API, but here read this RSS feed instead of something like serving up a static JSON file from a server somewhere.

As for the regex there's shipping, and there's doing it right. For all we know, they had to have it done before the 2 hours were up so they cut corners and got it done within the time requirement.

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 not) is working as intended.

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.

>i mean... you used a regex?

That was my initial impression, but after I reread the sentence I interpreted it as he used an RSS parser to get to the element with the data and then used a regex to extract the information from the data.

He didn't specify how the data was formatted inside the RSS element which leaves me to believe it might be something custom and not a simple CSV. This would be a perfectly valid use case for a regex.

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

  teach to the test

Yeah. At some point the candidate will become a professional candidate. I would rather stay a professional developer instead.

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.

If the data was formatted like this:

<outer><inner>1</inner></outer><outer><inner>Content: This is some random content. Value: 500 SomethingElse: 23423</inner></outer>

and the problem was to extract the value, the somethingelse and the content, then a regex using extractors would probably help a lot.

Seems to me like, you may not be as good as you think. If throwing a RSS feed at throws you then how you going to deal with real life legacy(sometimes not so legacy) crazyness?

While this may be true, the guy who has worked a bunch with RSS feeds will ace this question even if he is a substantially worse developer. This wouldn't be a problem if said technology was what the company actually used, but in this case it was not.

Wouldn't you expect someone who had never seen or heard of RSS before to be able to do a bit of research, find out what it is and work out how to parse and give an account of the steps they took?

A good candidate who had never seen RSS before might be better at that than someone who has spent their entire career processing RSS and never thinking about the details.

I think you are right, but then, you would not dismiss him based on time.

We're talking about XML basically. So he would have had to deal with the data in JSON if he had access to their API or XML in the test. Traversing XML isn't exactly the hardest thing to figure out and it took him an extra 100 minutes or so to figure it out. I personally consider the ability to learn one of the key things needed in a developer as you're constantly having to learn new things to achieve things you've never done before.

So is that a fail in your book ?

The guy actually learned the tech in less than 2 hours under pressure in an unfamiliar environment. If you fail him for that, the message you are actually giving is "I don't care if you can learn, every minute count in my business and if you don't know something you are out."

You seem to have missed the point.

Consider the following two developers. Who would you rather hire, and who will get hired under this system?

1. Developer completes the task, unfamiliar to them, in 2 hours, or

2. Developer completes the task, familiar to them, in 1.5 hours?

Maybe I'm biased (no Objective-C experience), but in the platforms I work with this is a 15-minute task, so I wouldn't hire either. There is nothing extraordinary about being familiar with XML or regular expressions.

Take your point, and it's probable that the employer had other concerns and picked a covering excuse.

(Some Objective-C flavour: NSXMLParser is a more appropriate solution than the one described)

One reason I picked 90 minutes for my example is that I was imagining a hypothetical task, and I don't think you would/should be left sat at a task for 2 hours where 15 mins was expected. I hope that wouldn't happen.

But if the only reason they hired someone else was because of speed, it seems really unreasonable. If he needed to spend 30 minutes reading about RSS and did a good job in the end, it really doesn't matter if he spend a little more time.

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.

Small piece of advice: Sometimes you get rejected from interviews for what seems like silly reasons, and most of the time they are really stupid. But always remember there is someone out there that would have gone into that interview, and completely blown their minds, even if they'd asked them to complete the task blindfolded in Scala. Make it your goal in life to be that person.

"That particular company’s APIs use JSON but they can’t give me access to the APIs, which I do understand. So instead I was given a URL to an RSS feed to work with. While that makes the task a bit harder for me since I never had to parse RSS feeds before, it also makes it even more pointless."

The company could have just as easily saved a copy of the results from the private JSON api.

Parsing XML with a regex? I see why you have been immediately rejected

He specifically said "since it was all inside a single tag". Without knowing what the payload of the tag is, its hard to say if regex was appropriate or not.

> its hard to say if regex was appropriate or not

I'd say it's never appropriate to parse XML with a regex. Even if you're just looking for something "inside a single tag", there are just too many gotchas like entities, CDATA sections, etc. Why bother with (or forget) any of that when there are well-tested XML libraries for probably every language, and many languages have it in their standard library.

I think you and I are reading the statement differently. I did not read it as he was using regex to parse the XML; I read it as he as using regex to parse the text contents of a particular tag that he extracted using a standard XML parser.

Of course regex is appropriate in some cases. You parse XML with a standard API, then use a regex on the contents of a single tag. For all we know, inside the tag could have been "img: foobar", regex works great in that case.

Reply on news.ycombinator.com