Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

More on Hiring Software Developers

hesh.am

Post reply on HN
Print view View original

31–40 of 47 posts

Re: More on Hiring Software Developers

#31

Post by Aqueous »

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…

If the data was formatted like this:

1Content: This is some random content. Value: 500 SomethingElse: 23423

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

Re: More on Hiring Software Developers

#32

Post by rickyc091 »

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

Re: More on Hiring Software Developers

#33

Post by kelseyfrancis »

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.

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

Re: More on Hiring Software Developers

#34

Post by hkarthik »

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…

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.

Re: More on Hiring Software Developers

#35

Post by kelseyfrancis »

vonmoltke wrote: post #17
marcosero wrote: post #14

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.

Re: More on Hiring Software Developers

#36

Post by ronaldx »

ricardobeat wrote: post #19
ronaldx wrote: post #4

Earlier quoted context omitted.

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.

Re: More on Hiring Software Developers

#37

Post by trustfundbaby »

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.

Re: More on Hiring Software Developers

#38

Post by tbrownaw »

pistle wrote: post #29
tbrownaw wrote: post #26

Earlier quoted context omitted.

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.

Re: More on Hiring Software Developers

#39

Post by fhars »

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…

That will solve itself once all the B players retire.

Re: More on Hiring Software Developers

#40

Post by gutnor »

johnnyfaehell wrote: post #9
r-s wrote: post #3

Earlier quoted context omitted.

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.

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 ne…

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

Post reply on HN