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.
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...
Rejecting people because they don't match your idea of an A player (I'm assuming 'perfection') is pretty 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.
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.
- 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."
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?
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.
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.
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
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.
<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.
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.
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.
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.
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.
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."
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.
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?
(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.
We're kidding ourselves if we believe that our dev work is "all-new algorithms, all the time." It's not.
The company could have just as easily saved a copy of the results from the private JSON api.
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.