I made a mention in an earlier post that I've been enjoying the StackExchange website for a while. One of the things that I've been finding interesting is how the site's Q/A format has been living up to most of the expectations that its creators had hoped for, and yet at the same time it has in a way been a failure.
Actually I find a lot more interesting about Stack Exchange than simply a view of its successes and failures, but I'm known for making the occasional bold and controversial statement so I'd better try and stick to defending my point of view without getting too far off topic.
A place for me to vent my spleen about processes, methodologies, philosophies, mythologies, tools, and systems which relate to the engineering of software.
Wednesday, 25 January 2012
Friday, 13 January 2012
Beautiful APIs
I am a big fan of the concept of the API. I have been ever since I realized in the earlier part of my career that you could actually share code across program "boundaries". One of my pet gripes over the years however, is that often when people think about interfaces, they instantly think about GUIs and the most dumbed-down representations that they can get away with in order to avoid "users" getting themselves into trouble. Even some of the more hardened API developers out there seem to find it hard to get their heads out of the mindset that a GUI is simply one type of interface, and that there are many more types that require the same attention to detail that a GUI does.
I have seen some really horrible API interfaces over the years, and truth be told I've even created a few horrible APIs of my own. Still, it hasn't all been a mere fruitless exercise, and years of hiding away in the proverbial 'dark corner' churning out API after API has taught me a thing or two. In that time, I guess you could say I've developed into a bit of an "API-Connoisseur", or as some of my colleagues might think of me as an "API-Snob".
I have seen some really horrible API interfaces over the years, and truth be told I've even created a few horrible APIs of my own. Still, it hasn't all been a mere fruitless exercise, and years of hiding away in the proverbial 'dark corner' churning out API after API has taught me a thing or two. In that time, I guess you could say I've developed into a bit of an "API-Connoisseur", or as some of my colleagues might think of me as an "API-Snob".
Wednesday, 4 January 2012
Odd recruitment practices when hiring software developer
A few years ago, I came across an article that suggested a recruitment practice colloquially referred to as posing the FizzBuzz question, intended to weed out totally inappropriate applicants who clearly didn't have a clue about how to write code. Personally, I had thought that the idea would cause a minor buzz (pun intended) for a while before it seemed to have finally run its course, and yet I came across a question at http://programmers.stackexchange.com/ that seems to suggest that the FizzBuzz question is still regarded by some as a useful recruitment tool.
I'll admit that I'm very surprised that people actually think that this can really tell them anything at all about an individual's abilities. I get it that this seems to be a possible way to catch out the new developers who either don't have the talent, or that have crossed over from other specialties with even less talent, but the tone of the original article suggests that it's common to sift through and possibly even interview 100 individual candidates and still need to use this "test". My question to anyone who has actually used a FizzBuzz-ism would be to ask if they actually know anything about recruiting technical staff at all, and programmers in particular?
Yes, I've actually had experience hiring staff for development roles. It's an arduous process, and yet one I would never leave to the agencies as you can just as easily do a word-search as the agency can, and save yourself a hefty fee in the process. The thing is, if you are screening candidates based on keywords, tricks and tests, you'll most likely lose the real diamonds underneath the rest of the chaff.
I'll admit that I'm very surprised that people actually think that this can really tell them anything at all about an individual's abilities. I get it that this seems to be a possible way to catch out the new developers who either don't have the talent, or that have crossed over from other specialties with even less talent, but the tone of the original article suggests that it's common to sift through and possibly even interview 100 individual candidates and still need to use this "test". My question to anyone who has actually used a FizzBuzz-ism would be to ask if they actually know anything about recruiting technical staff at all, and programmers in particular?
Yes, I've actually had experience hiring staff for development roles. It's an arduous process, and yet one I would never leave to the agencies as you can just as easily do a word-search as the agency can, and save yourself a hefty fee in the process. The thing is, if you are screening candidates based on keywords, tricks and tests, you'll most likely lose the real diamonds underneath the rest of the chaff.
Subscribe to:
Comments (Atom)