This is going to probably bite me in the ass because I'm looking for work at the moment and occasionally apply to interesting YC companies but since this has come up, I'm going to share my story here because of the negative experience I had with the company in question.
I had a phone screen with 500friends recently. They were late calling me, and the person I was scheduled to talk with wasn't even on the call. They had pulled some poor engineer off of whatever he was doing, shoved my resume in front of him, and said "go".
The list of things that our "interview" contained:
1) Late in calling me at our scheduled time.
2) Scheduled person was not present on our interview call.
3) Engineer that was put on the call was ill-prepared for the conversation.
4) Questions asked of me were a combination of very basic and others being completely unrelated to the nature of the position being interviewed for.
5) The scheduled person appeared at the end of the call barely long enough to say his name before hanging up on me.
6) Hung up on me suddenly.
#6 was what really got me. It was literally, "Hi this is <x>, we're out of time, click."
If you advertise a position as requiring a certain set of skills, then ask prospective employees about those skills! Go through their experiences and see if they're a good engineer outside of the narrow scope of "solves logic puzzles well". You might be surprised that someone who doesn't normally write linked lists in javascript or implement 2500 year old prime-solving algorithms on a weekly basis actually has skills and experience to contribute.
My personal recommendation for anyone considering 500friends is to skip over them. There's much better companies more deserving of your time and consideration, and you'll certainly be treated better.
## Just to add on, I don't have a problem with logic problems. But too many people only ask them and don't do real interviews. Yes, I can do linked lists in javascript. Does that tell you anything useful about what kind of engineer I am? No, it doesn't.
Not to excuse that sort of behavior, but this is a pretty typical HR experience in the Bay Area. Late calls, no-shows, awkward questions, either too easy or too hard, abrupt endings, obviously haven't read the resume, etc. Happens all the time, unfortunately.
Is it, though? Every company in the Bay Area I've ever worked for (and a few that weren't in the bay area) has hit multiple items on the parent's list. Even the ones who have their shit together and were a blast to work at gave horrible interviews.
Are you saying that my personality is the reason other people can't conduct an interview? I agree I don't interview well, but that has nothing to do with a third party I've never met being able to show up on time.
It was not a personal comment. The fundamental attribution error is that it turned out to be a compatible working relationship despite bad interviewing on the company's part. Aside from giving you an interview, nothing the company did during the recruiting process put the right person in the seat. It was just luck that it worked out, and just as often, if not more, it doesn't.
Granted, I think it was accidental on their part (ie: the person that interviewed me was newbie at Amazon himself and quite lost, but seemly the person that was going to interview me had a serious problem of sorts and could not do it)
I don't really understand this point of view, because implementing a Sieve of Eratosthenes is not particularly difficult.
I really don't know where to start with your comment. All I can suggest is that you sit in on about a dozen interviews by someone who actually knows how to interview and learn from that process. The thing about interviewing is that it is really just about due diligence. You are verifying that what someone represents on their resume is likely to be true. I think it's great that you are passionate about algorithms and various Sieves. You are a piece of a puzzle in a team. Someone who loves algorithms will pair well with someone who loves standard CRUD, as well as a UI designer. You are not looking for someone who knows exactly what you do plus more, you are looking for a team member.
Interviewing on "what you'll actually be doing" is also problematic, since most work is simple stuff that won't demonstrate the difficult edge cases.
Why not let your inferior-sounding candidate handle all of the CRUD and you can tackle those fun edge cases? For hacker news, I'm not sensing a lot of hacking going on here.
I am 100% positive that I can ask someone 10 questions that they don't know the answer to, and subsequently make them look like a fool. I can do this to PHD's, it's not hard. Get over yourself and start looking at candidates as potential team members, rather than opponents or competition.
I didn't get the impression OP thought that he was too good to implement a linked list in JS. Rather, he was looking for a company that was too good to spend interview time on a question containing low signal.
Like, the question itself is boring and cookie cutter. Why not implement a linked list or a tree in SQL (much more interesting for everyone)? Or a simple query language in JavaScript (a bit more practical)? Or tell have them do a code review of a simple webapp, have them critique it, then have them refactor it with you (much higher signal overall question)?
If your goal with an interview is to see how much bureaucratic bullshit a programmer is willing to put up with, by all means have them write linked lists. Have them write 5, one for each person interviewing them. If not, think about what you're trying to figure out about the person and craft the questions to suss out who it is you're talking to. "Program a linked list" is uncreative, and won't let you know very much.
You're missing the point of the linked list. A simple coding test like "program a linked list" during an interview is just a negative filter. Someone who can't write a linked list certainly is not a good programmer.
Parent was in no way suggesting he/she was "too good to implement a linked list". The point being made was that being a logic problem solving performing monkey doesn't really say much about your practical abilities in real world apps.
I believe the person is saying that it is okay to asked linked lists questions, but you must also ask practical questions.
In your case, why not ask about linked lists, and then ask why in a CRUD app the models are ending up in a mixed up state when you add a second application server?
A friend of mine had a very similar experience with this company and their C level team. Maybe some public feedback will help them reflect and improve.
Cargo cult interviewing at its best. It seems like they may be more experienced interviewing for jobs rather than properly interviewing candidates and building solid teams.
As I mentioned to you in my initial apology, we had a fire drill. That being said, the tardiness was inexcusable, and I talked to the developer about that.
Regarding our interview questions, they were meant as an "initial screen." We do ask more practical questions in person. However, we figure that most smart software engineers can write a linked list or prime number solver.
One way to interpret this is that the Agile Manifesto was published in 2001, so although it's possible you managed agile teams before 2001 it's unlikely, or if you've been successfully managing agile teams since before the manifesto and you're interested in a startup... what's wrong w/ you (seriously... if you're crushing it w/ agile for 12 years and now enterprises are all scrum-happy and you aren't making boatloads of cash consulting why are you considering a startup... oh, you're a serial startup guy... that's cool then you won't give a shit about some nonsense in a job posting, you'll work your network to get an interview or contact the founders directly and convince them you're worth talking to... and if you can't do that you're probably not VP material. No?)
One way to respond to this kind of job posting is "fuck that, I'm not going to waste my time w/ that shit".
Nah... Lightweight processes were discussed as alternatives to waterfall way back in the 90s during my software engineering courses. "Rapid application development" and RAtional unified process were the "hot" lightweight methodologies when I started work in 1996. Scrum has been with us since 1995.
I'm not sure if you're aware of this, but when the Agile Manifesto was signed, a giant red button was pressed that reset the entire industry's memory.
All that existed before 2001 was waterfall. Nothing else. Just waterfall. Only waterfall. You are mistaken in thinking that iterative delivery, spiral models, joint application development, daily build-n-smoke, test harnesses or any such practice or technology existed previously.
Then in 2001, Agile sprung fully-formed from the brow of Zeus and saved us. Agile has no predecessors whatsoever and completely invalides decades of careful observation, discussion and investigation by generations of software developers and managers.
All books and articles published before 2001 can be safely ignored, and nothing can be learned therefrom.
Agree, no debate about when you might have managed agile teams... could be you're Ken Schwaber (yeah, had to look up his name), but it then begs the 2nd question I raised... why would you want to do a startup? If you have 12+ years of experience with what is now a very hot process why, why?, WHY? would you want to work at a startup?
A VP role doesn't sound like a C role. It doesn't sound like a really big equity play. You're not going to be a founder w/ a big payout (probably). So why do it?
I'm repeating myself. It really doesn't matter at all... someone will apply or they will not and the company will hire the right person or they will not... you and I will go along with our lives just fine.
I think you're overestimating how hot of a skill that actually is...
But even if you could make "boatloads" of cash consulting, not everyone desires the road warrior lifestyle that goes along with consulting.
I do not know this startup. But I suspect your spot on... this feels like the kernel of a good idea, a way to filter out the wrong kind of application (not necessarily too old) and it's being interpreted (or misinterpreted). I honestly hope the best for this startup and hope some woman or man qualified to help them gets an interview... I suspect, for top candidates, the language will be awkward (but maybe top candidates... not guys like me... see through that).
I think it's a clever in-joke that didn't quite come off right. Which is a pity, a good VP Engineering would need both experience and a sense of humour.
It's not that people with 12+ years of experience are not as good. We were trying to screen out candidates (many of them who are smart) but have been "managers" for so long that they can't get their hands dirty and solve issues themselves (something you have to do at a very small team).
Don't take my word for it, 26% of people on our team are older than 38. If you're bored, check out some of their bios at 500friends.com/team
Admittedly however, this was not clear in our post, and it has since been edited.
This is totally off topic, and might be considered a rant, but I see this from time-to-time in startup land.
Not understanding titles.
First, this is for a "vp of engineering" that is "hands on". Are you really looking for an architect that codes? Perhaps a Sr. Engineer/Team lead? Do the engineers directly report to this "vp of engineering"? What happens when the team gets to big?
Second, you are locking yourself into something prematurely. If you want someone hands on with management experience and capacity to grow into a future leader, state that and start looking. Make your interview quick on the technical assessment, heavy on the social and ask "what would you do in ..." or "how would you handle this ..." type of questions. See if the person has 1. experience 2. common sense or 3. good intuition on process/people.
Lastly, what does the rest of the company look like when the VP of Engineering clearly has an inflated title. Are all the C level/VP level people equally inflated?
Anyway, sorry for the rant. It seems a common occurrence in Startupsville to see people running around with titles that mean nothing for the sake of having the title.
"Oh, cool. I'm the VP of engineering at blah blah".
Michael O'Church observed that if you're at or near the ground floor of a startup, titles are easier to get than money or equity.
Which seems harmless, but if and when money starts flowing, something primitive in the status=money&equity hindbrain clicks and such a title makes it easier to negotiate for a better deal.
I agree, an organization that views titles as cheap/free either does not have the imagination to forsee the scenario you describe or they do not seriously expect to grow.
>>First, this is for a "vp of engineering" that is "hands on". Are you really looking for an architect that codes?
Sorry but why can't a VP of engineering be somebody who should code(even if occasionally) or some who could be competent at a code review. Its precisely this kind of attitude that gives ammunition to the MBA culture of appointing people who are clueless about their current job to manage the best people under them.
The net result is getting people appointed who know nothing about the people they managing, or the line of work. And just take blanket common sense based decision which most of the times are wrong with regards to the domain they lead.
Regardless of who you are- architect, VP or whatever fancy title. If you claim to be the leader of a group of people with some specific skills you should be somebody who at the very least has mastered those skills.
According to me anybody who claims to lead a group must be the best among that group, in the job that group performs.
> According to me anybody who claims to lead a group must be the best among that group, in the job that group performs.
I'm sorry, and this is going to sound harsh, but this is awful, awful advise. And pitifully shortsighted.
So, a manager that leads developers should be the best developer?
What about a director that manages developers AND architects? Or developers AND QA? Does the director have to be the best at both those functions? Or some "best of the combination" of the two?
What about the VP? Now the VP of engineering likely leads (in a large enough organization) directors of QA, engineering, product, maybe some other roles like IS as well. In turn, they might lead managers or some function directly. Is this VP the uber of all those roles?
And then we get to the CEO.
No, this is terribly short sighted. Amazingly so.
In sports is quite commonly known that the best players usually make terrible managers. There are quite a few theories on why, but the end result is that very few great players have been great managers (oddly enough, MLB has more ex-player managers than the other leagues, and is more immune to the above criticism...again, many theories why). In fact, quite a few of the best managers in some sports are typically borderline players, if they played at all. Using your "best should lead" theory, only the best ex-basketball, ex-football, ex-baseball players should be running teams in the NBA, NFL or MLB.
No, the best leaders should lead. Doesn't matter if they are not the best developers And how good a developer one was becomes irrelevant past "team lead" or manager at best.
> According to me anybody who claims to lead a group must be the best among that group, in the job that group performs.
I think this is an error. Taking your best coder and then spending their time on not-coding is wasteful of their talents.
Furthermore, insofar as you create competition to hold that position, you're creating a destructive work environment. Software development is a cooperative activity that can't be efficiently partitioned.
>>Taking your best coder and then spending their time on not-coding is wasteful of their talents.
Or the way I look at it, such a guy in a leader ship position can mentor young passionate folks to be just like him.
>>Furthermore, insofar as you create competition to hold that position
Having competent guys compete for a position is far better than promoting a total idiot to lead such guys.
>>you're creating a destructive work environment.
How is appointing a competent guy creating a destructive work environment, and appointing an incompetent guy not creating a demotivating environment.
Most demotivating part of my day is when I spend time with my higher ups, explaining them some very basics things like SQL or regular expressions or about network call latency which most of the times they have no clue of. Many times its so bad, you really have to talk to them like you talk to your 9 year old nephew and even after hours of explaining things are so bad they can't really get simple things like the difference between a DOM parser and a SAX parser.
I am not saying the guy must code like a champion 24x7. But he should have atleast been some one who has built a thing or two under tough demanding deadlines. Some one who has leaned stuff doing it by experience and not just some guy whose only known accomplishment is being at the right place at the right time, riding an economic wave or being some god father manager's yes man.
>>Software development is a cooperative activity that can't be efficiently partitioned.
> How is appointing a competent guy creating a destructive work environment, and appointing an incompetent guy not creating a demotivating environment.
Because you based it on competition.
Holding that position, which presumably comes with better pay, perks and a résumé line item, is a zero sum game.
Everything good that programmer A does for the company now directly disadvantages programmer B and vice versa.
Do you think this creates conditions conducive to cooperative efforts like developing and maintaining complex software?
If you want to pick a leader, pick a leader yourself. Boohoo, it's hard and you might hurt people's feelings. Well too bad. Picking leaders is itself an act of leadership. Too many senior managers shirk the responsibility of growing a cadre of good managers by connecting it all to numbers that encourage destructive behaviour. It's the lazy and gutless way to lead.
See Measuring and Managing Performance in Organizations for a full enumeration of why having people compete for a tech leadership job would easily destroy any small company.
You would be correct if compensation of any individual in our society would be independent of their title/position in the hierarchy. Unfortunately its not.
Either way competition is inevitable- If its not from the inside, it will be far worse- from the outside. And in most cases companies have to acqui-hire people or purchase out an entire product line because they just can't get innovation out of their own people.
But the sad fact is its not current employees are at fault here. Unless you are super foolish, why should you ever work hard when some guy who isn't doing 1/10th work you do or is 1/100th as competent take all the credit, money and power stealing your work? The net result is no one contributes, the company struggles and buys their life saving kits every now and them from the outside.
And no competent person will accept a incompetent person over them, especially when getting a job or doing a start up/side project is so easy these days. How many times have we seen companies that claim to hire all super candidates with all those algo/ds questions routinely acquire start ups at big prices, yet they can't get something half decent out of their super star regular hires.
If you look down below, you will see it all gets down to incompetent middle management.
>>Too many senior managers shirk the responsibility of growing a cadre of good managers by connecting it all to numbers that encourage destructive behavior.
No, they do it because they know competent folks will grow and become a threat do their positions.
Most demotivating part of my day is when I spend time with my higher ups, explaining them some very basics things like SQL or regular expressions or about network call latency which most of the times they have no clue of.
Why are you doing this? Most "higher ups" I've worked under have nearly zero interest in highly-technical explanations of what I'm working on. Interacting with managers should be an exercise in plain English.
> Furthermore, insofar as you create competition to hold that position, you're creating a destructive work environment. Software development is a cooperative activity that can't be efficiently partitioned.
Seen way too many of these kinds of management structures. The management decides to appoint the crony as the lead, because picking the best developer is "wasteful" and creates a "destructive work environment". The amount of cringe inducing perversion of logic in the comment above is a tragedy because of its pervasiveness. On the flip side, these kinds of organizations are not too hard to avoid, doomed startups and successful behemoths - both fit these criteria. A smaller company with decent growth is probably the better bet.
This company has been looking for a VP of Engineering since at least last summer. I applied for this position back then. They got back to me with a ridiculous busy-work problem they wanted me to solve. I forgot then about them.
My co-founder was previously the (only) VP of Engineering (and did a great job), but we mutually parted ways after the Series B. These things happen...
Your earliest press releases are from 2 years ago. How can you have lost that "only" VP of Engineering who as your co-founder was part of the team back then, be recruiting for the position a year ago, and be recruiting for the position now, but this time it is only been for the last 3 months ... well, I suppose you could have just not actively tried to fill the position during the gap, but that at least suggests it's not really that important. And why didn't you mention that?
I am not a lawyer, but is this not illegal in the U.S.?
Checking The U.S. Equal Employment Opportunity Commission website[1], it says under the "PROHIBITION OF AGE DISCRIMINATION" section:
(e) Printing or publication of notice or advertisement indicating preference, limitation, etc.
Theoretically, you could have worked the first 20 years of your career doing mainframe and SAP conversions (or, running a landscaping business), and then switched to agile software development within the past 10 years.
They don't say 12 years total experience, just less than 12 in Agile.
It's simple. People who have more experience generally demand higher salaries. The company in question is probably seeking someone who's fairly experienced but doesn't have the budget to afford a superstar.
Seems like they're breaking the law to me, but it's not completely black and white. In the odd chance it would happen, wouldn't saying "20+ years of experience required", prevent anyone younger then 20 years from joining the company?
Also, requiring experience is reasonable anyway since its easy to make a case about why it's required to do the work. I'd dying to here what kind of BS hand-waving argument could be constructed for why having too much experience prevents you from doing the work.
I'm not a lawyer but my guess is requiring years of experience isn't discrimination since it would only help, not hurt, the protected class (older workers).
The minimum isn't the important part - they're putting a cap on experience at 12 years which will exclude the vast majority of protected workers, basically anyone who didn't switch careers very late.
The act of "discrimination" per se is fine. In fact, when you select one candidate among many, that's exactly what you're doing. Exercising discrimination. It's just required to be the right kind of discrimination -- based on actual qualifications and perceived capabilities to do the job at hand.
What you are not allowed do is discriminate based on criteria that are not part of essential qualifications for the job. And I for one can't conceive of one single thing that disqualifies, say, Jeff Dean, from holding that job over a candidate a few years his junior.
Nah, they can say "the Agile Manifesto was published in 2001, we were just screening out bogus resumes". Of course anyone submitting shitty resumes, who really wanted the job would just tailor their resume to make it appear that they'd been managing agile teams since the day after the manifesto was published. Probably not illegal.
Agile is only 12 years old [1], so it might be related to the old programmer joke about HR posting job ads that require 'x' years experience with 'y' year-old tech, for some x > y.
But that's grasping at straws, and if that is the intention it's a really unfortunate way of putting it.
"agile methodologies" are certainly not only 12 years old. The Agile Manifesto coined the phrase "agile" in 2001 (read your link wikipedia page), but the ideas were around long, long before this.
I'd claim that I subconsciously 'corrected' it, but let's be honest: what good would a post about a typical HR error be without a typical programmer error!
500friends founder/CEO here. Look at my team - 500friends.com/team. Most people are who you may consider to be "old." And we wouldn't be where we're at without them. We do not discriminate against age.
It's not ageist. It doesn't say People who are 50 need not apply. From reading this job posting, someone who is 80, worked as a mechanic, a waiter, a clerk, and then picked up some newfangled technology might qualify.
Besides the whole Agile not being codified for more than 12 years thing, if you've been out of the loop managing for 12 years, they say they don't want you. Part of the process apparently involves showing that your technical skills are still there.
As i posted above... Lightweight processes were discussed as alternatives to waterfall way back in the 90s during my software engineering courses. "Rapid application development" and RAtional unified process were the "hot" lightweight methodologies when I started work in 1996. Scrum has been with us since 1995.
And yes, it's blatantly ageist... It falls under the disparate impact provision:
"In addition to prohibiting intentional discrimination against older workers (known as “disparate treatment”), the ADEA prohibits practices that, although facially neutral with regard to age, have the effect of harming older workers more than younger workers (known as “disparate impact”), unless the employer can show that the practice is based on an RFOA."
It appears to say that they want (ideally) someone with 5-12 years of experience managing a team, after a successful career as an individual contributor. To me, that implies that they don't someone who has been just a manager for the last twenty years.
So it's possible that you could have been a developer for twenty years and then a manager for ten years and still be within their ideal range. Considering the CEO is about 24 years old, it's hard to believe that that is the case, though it is possible.
Maybe they assume someone with 12+ years of experience would demand a higher salary than they can offer? They might identify such a candidate with a C-level position like CTO more than a VP position. I don't really know; I'm just trying to come up with a non-ageist explanation.
It might not be any different from how someone with 5+ years of experience normally wouldn't be considered for junior roles.
83iq... where there are more PMs than products and executives outnumber engineers!
19yearsold... with free dinner after 8:00, unlimited vacation (subject to managerial approval) and equity (at-the-money options on 0.02%, subject to vesting and cliff)!
This posting is so bad and offensive, I hold it against the leadership team of this company. I certainly would think less of someone if someone else mentioned, "Oh they were on the leadership team at 500friends".
500friends founder/CEO here. Look at my team - 500friends.com/team. Most people are who you may consider to be "old." And we wouldn't be where we're at without them. We do not discriminate against age.
What we meant is that we're looking for someone who has coded in the past decade. Someone that has been managing 1,000 people at Oracle may not be the right fit for a company of our stage. Make sense?
Hi Justin. It makes sense, but why didn't you say something more like that to begin with? Something like "Active development skills are part of the hiring criteria". You already mention doing Ruby development -- someone who hasn't coded in a decade, probably doesn't have much Ruby experience.
It just seems odd that of all the possible ways to ask for what you describe above, you choose arguably the most offensive and least effective way to do so. And I think as a marketing company, you should know better. The message matters -- not just the intent.
Seriously, think about a better way to phrase the requirement. There are several preferable ways to phrase the question (not just from a legal perspective, but even in terms of simply capturing the pool of candidates you desire).
The reason for this is that if you haven't been coding (just managing) for 12+ years...you probably are not "hands-on" enough for a company of our stage.
We have gotten a lot of very smart but "big company" people who had applied for this position.
Sorry for the confusion however, most of our team is actually MUCH holder than the typical start-up: 500friends.com/team. We may be a lot of things but are definitely not ageist.
We want someone who has less than 12 years of MANAGEMENT EXPERIENCE. The reason is that if you haven't been coding for 12+ years...you probably are not "hands-on" enough
This arbitrary cutoff makes absolutely no sense. I'd like to see your quantification of skill drop off per year of management.
If what you are wanting is a hands-on technical manager, then you need to say so.
And it shouldn't matter if the person has been hands on for 5 years or 20.
But I feel I'm being a little too generous regarding your motives here.
I think I know what you mean, but really, there must be a much better way to express this. For instance, instead of being quantitative, be qualitative. Don't say, "no more than 12 years", but say something like, "but still be able to code your way out of complex, practical software problems." Or maybe "code your way out of FizzBuzz"... Whatever. Just don't put a numerical value on it, because it is 1) insulting to many, 2) legally questionable, and 3) unlikely to actually find what you're looking for.
I had an interview like this at Willow Garage about 5 years ago. The interviewer said he would call at 8:30am. He called at 8:54 and sounded like he'd had about 2 hours of sleep. Then he said he had a 9:00 meeting and would call me back at 12:30pm. He called about 12:55 and proceeded with a lackluster interview during which he confused knowledge representation with graphics programming. Perversely, the interview made me want to join Willow just to see the train wreck in progress. (In their defense they have produced some good robotics platforms since then.)
Not sure why "best of the best" would be so inclined to join a company that has mission to help marketers (primarily retailers) increase their customer lifetime value.
The only reasoning I can come up with that could possibly support this is maybe they have the idea in mind that those with more than 12 years experience would be less able to adapt to newer ways of thinking?
I work with a few of them actually. I loved college but these guys were cutting their teeth on tech when I was cutting mine on beer pong. All of them are too smart to ever think about a job description like that.
In our original job post, we had specified that the ideal candidate would, "not have more than 12 years of MANAGEMENT experience." We UNDERSTAND that this could be misunderstood to indicate that we do not value experienced people. As you can see from the seniority in our team however, this is far from the truth. The intent here was to indicate that we are looking for a "hands-on" VP of Engineering. Someone who has coded in the last decade and can solve issues themselves (rather than asking their engineering manager to then delegate it to a developer :).
Don't take my word for it, check out the people who work at my company - 500friends.com/team. 50%+ are 30+, and 25%+ are 38+
I hate the fact you have to say that...it pisses me off to hear this. I was lucky I had minimal loans, and school was 1/2 the cost. If I can give a word of advice, spend less on car #1 and attack that loan, pay it off. Get to 0 debt.
What if we gave them the benefit of the doubt, and they were posting "no more than 12 years" because they want someone who's seen what happens but not someone who is steeped in it? Someone who is familiar with the problems but hasn't dealt with it so long that they are still naively excited about trying to change it?
For example, if x guy has been doing TPS reports for 12 years,maybe they are figuring that he has already just adjusted to a gotta-do-my-TPS-reports mindset?
it seems to have been removed (the 12 years part) btw.
i saw it earlier. perhaps it was a joke - agile manifesto was published 12 years ago? (an argument for this is that 12 years is a strange number to use otherwise).
[edit] and now there's a broken link on the front page saying that 26% of their team is older than 38. i hate to say it but (1) i told you so (2) do people lose their sense of humour with age? (3) i am 46 myself...
It actually makes sense. It's not about age. Middle management has an expiration date. If you've been a middle manager for 15 years, that's bad bad bad. (Being an IC for 15 years is respectable; but once you move into management, you should make director in 5 years and VP in no less than 10.)
Programming has an ageism problem largely because it's run by career managers (who think all of us want to be them-- and we don't); engineers themselves aren't ageist. Management is where the ageism comes from and it's even worse in their world. It's not that they care about age so much as they want to avoid hiring terminal middle managers, and I can't blame them for the latter. This fact has absolutely nothing to do with age, but terminal middle managers are toxic.
You can be fairly confident there some startups out there founding by 20 somethings, populated by 20 somethings, who think having someone over 30, or certainly over 40, on their team or even in their office would be akin to the plague. They would probably place them in the same camp as their parents.
I totally understand why coders like Agile, hey I like it because hacking code is the fun part :) Its also kind of a good fit for the app store era, where you throw something out there and see if its sticks before you actually develop most of it. Not entirely sure its actually a good way to develop nontrivial software.
It's not that people with 12+ years of experience are not as good. We were trying to screen out candidates (many of them who are smart) but have been "managers" for so long that they can't get their hands dirty and solve issues themselves (something you have to do at a very small team).
Don't take my word for it, 26% of people on our team are older than 38. If you're bored, check out their bios at 500friends.com/team
Admittedly however, this was not clear in our post, and it has since been edited.
If in your 20's you feel, some one over 30's is a plague. You have a big reason to be worried, because you will be in your 30's in less than 10 years. That's too less time for comfort.
I had a phone screen with 500friends recently. They were late calling me, and the person I was scheduled to talk with wasn't even on the call. They had pulled some poor engineer off of whatever he was doing, shoved my resume in front of him, and said "go".
The list of things that our "interview" contained:
#6 was what really got me. It was literally, "Hi this is <x>, we're out of time, click."If you advertise a position as requiring a certain set of skills, then ask prospective employees about those skills! Go through their experiences and see if they're a good engineer outside of the narrow scope of "solves logic puzzles well". You might be surprised that someone who doesn't normally write linked lists in javascript or implement 2500 year old prime-solving algorithms on a weekly basis actually has skills and experience to contribute.
My personal recommendation for anyone considering 500friends is to skip over them. There's much better companies more deserving of your time and consideration, and you'll certainly be treated better.
## Just to add on, I don't have a problem with logic problems. But too many people only ask them and don't do real interviews. Yes, I can do linked lists in javascript. Does that tell you anything useful about what kind of engineer I am? No, it doesn't.