More on Hiring Software Developers
1–10 of 47 posts
Re: More on Hiring Software Developers
#2Seems 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?
Re: More on Hiring Software Developers
#3Seems 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.
Re: More on Hiring Software Developers
#4Seems 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?
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?
Re: More on Hiring Software Developers
#5Seems 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.
Re: More on Hiring Software Developers
#6Seems 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?
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.
Re: More on Hiring Software Developers
#7Earlier 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.
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.
Re: More on Hiring Software Developers
#8Seems 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?
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?
[deleted]
Re: More on Hiring Software Developers
#9Seems 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.
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.
Re: More on Hiring Software Developers
#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 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.