How Can We Achieve Age Diversity in Silicon Valley? | Hacker News Reader

How Can We Achieve Age Diversity in Silicon Valley?

medium.com

420 pointssteven502 comments

I'm in my 50s, and I used to say that I never saw age discrimination. Then a couple of weeks ago, I interviewed for an Internet company, and my age and experience was commented on by the majority of the interviewers. Which is fine, since most of the comments were positive (e.g., we need people with more experience because we have so many new graduates), but it was still a bit strange.

Then the technical interview came, and one of the interviewers was instantly hostile as soon as he saw me. It was weird. Weird to the point where the other tech interviewer started playing good cop, saying things like "he just covered that" and "no, that's true". Whiteboard coding is strange enough, but doing it with zero feedback and a hostile interviewer who keeps trying to push you in bad directions (inheritance over composition, singletons, etc.) is, well, interesting. The application came back with the inevitable "good skills but bad culture fit" euphemism.

As with all discrimination, the unnerving part is just not knowing. Was it really age discrimination? Or maybe I just looked like this guy's hated father or ex-boyfriend or something. Or maybe he's just a bad interviewer with low skills, and really didn't understand the stuff I was telling him (I usually sneak in a couple of technical questions for the interviewer and he blew those questions); that's hard to judge when there's no follow-up questions. Or maybe at the end of the day it was just money and the company didn't want to admit it. Who knows? I'll never know, and I suspect the company won't either.

> Then the technical interview came, and one of the interviewers was instantly hostile as soon as he saw me. It was weird. Weird to the point where the other tech interviewer started playing good cop, saying things like "he just covered that" and "no, that's true". Whiteboard coding is strange enough, but doing it with zero feedback and a hostile interviewer who keeps trying to push you in bad directions (inheritance over composition, singletons, etc.) is, well, interesting. The application came back with the inevitable "good skills but bad culture fit" euphemism.

Wait, you think the companies that have to move fast have the coddling environment?

Sounds like a similar experince to one I had where interviewer nr2 clearly had made made up their mind before walking into the room. So 30 mins into an interview that was going swimmingly - in comes sour face and contradicts everything I say. It wasn't a "strategy", it was just some $$$$ in a bad mood who didn't like my name? age? some other factor? I hope I can just roll with it next time but I got really pissed at the time as I knew I was suited to the job, but wasn't given a fair chance. It gets you down when you are 'between jobs'. Funnily enough, I now work in a different division of the same company and this person was brought in on a project I was on. I don't think I was remembered and thankfully I had recovered my professional composure so I didn't mention our first meeting.

It's a bit indulgent but if I knew the guy wasn't going to perk up I'd just bring it forward.

"I'm getting some hostile vibes. Have I upset you or am I mistaken?"

It'll either give the guy a reality check or speed things along. No sense in us wasting our time.

"confrontational - poor culture fit"

Are you being tongue in cheek about a possible reaction, or does that behavior actually seem confrontational?

I feel like the wording given spoken with an appropriate tone (somewhere between matter of fact and conciliatory) would be direct but very reasonable. If things deescalate, great - and if the employer reacts aggressively, it's a win as well - you found out early they don't tolerate people sticking up for themselves. Time to bounce.

I was being tongue in cheek, but there is a problem of sexism where a man will talk over women. If those women assert themselves they're often not seen as assertive or powerful, but pushy and bitchy and shrill. When black people do it they're seen as aggressive.

Stopping people talking over others makes life better for everyone - you don't want to exclude people (men or women) because they don't want to bother shouting down an over-confident asshat.

I understand this is a problem. But any unassertive person has these problems. And being called 'shrill' or 'aggressive' can be fine at work.

Shouting down is not the solution. Its better done by expressing annoyance, immediately, when talked over. Maybe white males learn this early on the playground. But anybody can learn this.

I understand this is a problem. But any unassertive person has these problems. And being called 'shrill' or 'aggressive' can be fine at work.

That works after you have the job, not before.

"we promoted Bob because he's assertive. We didn't promote Ann because she's shrill."

"we promoted Bob because he makes good decisions and motivates others to follow him. We didn't promote Ann because she's trying to enforce her suboptimal decisions by using her authority"

Your quotation is less faithful to what actually shows up in performance evaluation than the comment you responded to.

Maybe, but DanBC is likewise only highlighting one option.

In my experience, that is by far the less likely. Leaders are called leaders because they lead people who choose to follow. If you're forcing others to follow, you're not a leader, you're an authoritarian. I haven't met many of the latter, but plenty of the former, none of which I would describe as "assertive".

Here's some actual data on actual performance reviews.

http://fortune.com/2014/08/26/performance-review-gender-bias...

When breaking the reviews down by gender of the person evaluated, 58.9% of the reviews received by men contained critical feedback. 87.9% of the reviews received by women did.

Men are given constructive suggestions. Women are given constructive suggestions – and told to pipe down.

There’s a common perception that women in technology endure personality feedback that their male peers just don’t receive. Words like bossy, abrasive, strident, and aggressive are used to describe women’s behaviors when they lead; words like emotional and irrational describe their behaviors when they object. All of these words show up at least twice in the women’s review text I reviewed, some much more often. Abrasive alone is used 17 times to describe 13 different women. Among these words, only aggressive shows up in men’s reviews at all. It shows up three times, twice with an exhortation to be more of it.

>Maybe white males learn this early on the playground. But anybody can learn this.

You're missing the point. The point is the -exact- same behaviors are seen through a cultural lens.

How do you know it's the exact same behaviours? Maybe there actually is a difference in behaviour? Your quite does sound plausible.

Because its been repeated over and over and over again in research.

Here's one example:

http://mobile.businessinsider.com/psychology-biases-that-ben...

In 2003, Frank Flynn taught a Harvard Business School case study on Silicon Valley entrepreneur Heidi Roizin to a class at Columbia. Her story is epic: After graduating from Stanford's Graduate School of Business in 1983, she founded an early Silicon Valley software company before becoming president of Software Publishers' Association and later serving as Vice President of World Wide Developer Relations for Apple. Then she became a venture capitalist and Stanford lecturer.

But when those Columbia students read her story, only half of them knew her as Heidi Roizin. The other half read the same story with a changed name: Heidi became Howard.

The students reacted very differently to the same protagonist, depending on the perceived gender.

"Although [students] think [Heidi is] just as competent and effective as Howard, they don't like her, they wouldn't hire her, and they wouldn't want to work with her," Flynn later said. "As gender researchers would predict, this seems to be driven by how much they disliked Heidi's aggressive personality. The more assertive they thought Heidi was, the more harshly they judged her (but the same was not true for those who rated Howard)."

In short, men are liked for being assertive, while women are disliked.

When black people do it they're seen as aggressive.

Aggressive or "Angry". It takes a bit of conversational judo to avoid such an appearance. I'm a big black guy. (6'2", 255 pounds) It rarely goes well for men like me if we're perceived as angry or aggressive.

When someone starts talking over me, I become not only quiet but still. As close to motionless as possible. I even slow down my rate of blinking. Remaining silent and motionless forces all attention in the room onto the person who is speaking.

It makes them and anyone else in the room acutely aware that this person just cut you off and has breached standard etiquette. At that point, the pressure to be polite usually kicks in "Oh, I'm sorry. You were saying?"

This is a really great communication hack! It's a pretty poor comment on society at large that you've had to mitigate your communication based purely on how people judge your appearance, but thank you for sharing it.

If one is aware of the biases of others, they can be used to one's advantage.

This happened a little over 20 years ago.

I was shopping at the mall, near Christmas and the place was packed. There were some really long lines and I said to my friend "Watch this", then walked over to some items that were near the item that I wanted to buy. I started picking up, examining and putting back small items that were on the shelf. I was sure to do it in a way that showed I was putting each item back in its original position before moving on to the next one.

In under 90 seconds, a salesperson approached me and asked if I needed help. I said "Yes, I'd like to buy this" and reached for the item I wanted. He proceeded to take the item, carry it to an unused register, ring me up and complete the sale. I was out of the story in 5 minutes while the other people in line had barely moved.

My friend (who is white) looked at me and asked "What just happened there?" and I explained to him that I was taking advantage of racist perceptions to improve my own shopping experience.

That is truly amazing! Deren Brown would approve!

Can you explain to me what racist perceptions that were, and why you got what you wanted? I don't have experience that would help me decode that situation...

Black people are seen as all being thieves. The shop keep assumes thief, goes to investigate, and is subverted to beat the queue.

There's a relevant recent article on HN:

https://news.ycombinator.com/item?id=10386387

http://m.eastbayexpress.com/oakland/racial-profiling-via-nex...

Yes, I've assumed as much, but I don't understand why would that make the assistant help him? To get him out of the store quicker?

Also, why was he doing what he was (taking stuff, looking at it, putting it back where it was)?

I didn't understand all of this at the time, I just knew that it worked. Later, when I worked in retail, I learned why.

Retail employees aren't supposed to stop shoplifters. They are expected to take opportunities to turn potential shoplifting incidents into sales.

I used the perception that the salesperson had of me as a young black male to my advantage. I picked things up and was conspicuous about putting them back in the exact same place to draw attention to myself. I was behaving in an incongruous manner, not necessarily a suspicious one. Basically, I was doing something different than the other people there and that got someone's attention. I thought that they'd assume I was looking to shoplift and someone would come over to "help" me while other customers were still waiting. I was right. Ringing me up right then and there guaranteed that the sale took place instead of sending me off to wait in line where I might just walk out.

Brilliant.

>I picked things up and was conspicuous about putting them back in the exact same place to draw attention to myself. I was behaving in an incongruous manner, not necessarily a suspicious one. //

Based on your description you behaved in a suspicious manner.

People don't browse like that in general but shoplifters do - you didn't behave like a "young black male" [ie like any random person] you behaved like a person that the security guards have seen stealing things before, you pick up lots of items, look around a lot, have an accomplice to act as lookout/provide distraction/carry-goods. Small items are great as you can pick two, palm one and then make a show of replacing the other. Similarly in an area with high value goods a shoplifter will "browse" lots of items as they're waiting for their moment whilst a shopper, particularly getting a large-ticket item, will go straight for the item as that's why they came.

Now it might be that they noticed that behaviour initially because you were profiled as suspect based on racial prejudice, but as soon as you enact the behaviour then the response was response to shoplifter behaviour rather than racial prejudice.

I'd be interested if anyone knows about use of CV to flag potential shoplifters based on standard behaviours?? Seems the tech is there to do that.

It's my contention that my demographic information is why my behavior was regarded as suspicious.

Had I been a middle aged white guy, it would have been seen as the behavior of an interested customer.

To just put it out in the open, this was a Radio Shack. I have been going to Radio Shacks since I was about 7 years old and looking through all of the hobby electronics. Over the years, I discovered that I could get the attention and assistance of a salesperson at will.

Doesn't the fact you can get the attention at will disprove your hypothesis? It's the behaviour that gets the attention, otherwise you wouldn't be in control. If it weren't the behaviour then you'd get approached as often when you don't do as when you do.

As I said before it could be that you get observed more because of your demographic, but if you can perform a behaviour that gets direct attention then it's not your race or other aspects of your appearance that's causing the staff action.

Just stand where you are and start swearing loudly will work too, you'll get a member of staff, they'll say "can I help you" - it's the usual attempt in a commercial environment to be non-confrontational when really one means "you look suspicious, why are you here" - you then say "please ring this up for me". Chances are they see that will get you out of the store ASAP, which would be their intention during the approach.

I work in a store, it's really obvious when people don't follow standard purchasing/enquiry patterns.

Doesn't the fact you can get the attention at will disprove your hypothesis?

Not at all. What would be perceived as customer interest as a non-minority customer is perceived as suspicious as a minority customer.

So you consider the behaviour to be normal? It's very difficult to behave normally when focussing on a particular behaviour, most people are not very good actors IME.

Would be interested if you can recreate this as a demonstration; also a video showing the behaviour would be great, I'd certainly attempt a duplicate.

>What would be perceived as customer interest as a non-minority customer is perceived as suspicious as a minority customer. //

I perceive problems with this line of thinking - for example any young solo male at the store I work at is suspicious. Does that mean I'm ageist and sexist? No, just that this demographic is contrary to the normal use of our services; moreover the only major theft we've had was by someone in this demographic.

We might fail to notice someone else stealing because our attention is elsewhere whilst with people in that demographic our attention will be much more tightly focussed; according to our records this has never happened however.

In your opinion is it wrong for us to behave in this way?

So you consider the behaviour to be normal?

Depending on how you define "normal". If you mean acting like everyone else, then absolutely not. My goal was to be incongruous.

If you mean acting calmly and naturally, then yes. I wasn't nervous because I knew that I wasn't doing anything wrong. I wasn't doing anything that would get me in trouble.

If you are watching the young males, how can you be sure? What kind of inventory shrinkage do you have?

In your opinion is it wrong for us to behave in this way?

We all have our biases. Whether or not it's wrong is debatable but if you miss a shoplifter because you were focusing your attention on the wrong person, that is your fault.

He deliberately looked like a shop lifter, so someone came over and got him quickly out of the store, which made both of them feel better.

Putting the item exactly back in place, is that to increase the clerk's suspicion of shoplifting, or defend against accusations of it?

To draw attention to myself.

If the norm is for people to put it back close to the same spot, I make sure to do it precisely, because it's incongruous and will draw attention.

My goal was to make them think "What's that guy doing?" as opposed to "I think that guy is trying to seal something."

You can pick 2 items if they're small, put one back to attempt to appear like you didn't take anything; works with clothing too. Suspicious behaviour looks suspicious.

How often do you do that? Does it work consistently? I'd like to try it and see if it works - I have a problem where when I'm at dinner with my family, the two old men in the room (my dad and uncle) will shout over the other three people at the table, excluding us from the conversation. I wonder if this technique would work, but I have the feeling they wouldn't even notice.

It doesn't happen often and consequently, I don't have to do it often. I doubt that it would work on family.

In an argument, a common technique when someone yells at you is to lower your own voice. It makes the other person angrier and look stupider.

I thought the point was to demonstrate you're not being violently aggressive [with your voice at least] and to get the person to have to pay closer attention, ie move in, at which point they risk escalating too much if they continue being very loud.

This to me is a defusing technique rather than an attempt to increase the other persons anger and to humiliate them.

Guess it depends on what you want to get out of the situation: you could adopt a quiet voice and non-threatening demeanour but be highly offensive with your language and probably achieve the ends you mention quite well.

It's not fair that you have to do this; yet I'm glad you have found a way to mitigate the cost of unfair treatment, and I hope people will curtail their biases in future.

About the not-blinking, though --- that seems like staring, which I would guess would get lumped in with the body language that gets called aggressive. (I'd guess that blinking more makes you look surprised and wounded, which is the effect you are going for in this scenario)

I still blink but I do it at a slower rate and I deliberately slow the blinks.

I suppose it's more art than science to not appear to be staring but to be blinking less often.

I do the same thing. There really isn't any point escalating the situation when someone is clearly being out of line and unfairly interrupting you. It almost always devolves into a shouting match. And then drama ensues, and someone has to mediate to resolve, and so on, etc.

I've also seen others that react in different ways. Some of them react a little too-hastily to being interrupted with some sort of hostile comment (even after doing it others), and don't adapt to the situation. There are some discussions that are lively and very back and forth.

Really, at the end of the day we're all just there to solve problems with good solutions. If you have a good idea, as long as no one is actively blocking/ignoring it, it needs to be considered.

Thinking and vocalizing being asynchronous processes, "people talking over others" isn't always as straightforward as it may seem.

At what point do you determine that someone is talking over someone or that the person being talked over just attempts to dominate the entire conversation?

I think both behaviours are problematic.

> but there is a problem of sexism where a man will talk over women. If those women assert themselves they're often not seen as assertive or powerful, but pushy and bitchy and shrill

I don't think that's a problem with sexism, but with how a person does it. If you're used to talking over others, you usually do it in a "smooth" way, when other people make pauses, or you say something very relevant. On the other hand, when someone gets annoyed that they can't finish, them being annoyed is off-putting, and they also often say things like "let me finish first" when you already know what they will say, so they come off as struggling to gain power and influence.

Edit: I think, on the other hand, that making people communicate faster and dynamically search for the optimal speaker makes communication more efficient and is better for everyone. No shouting needed.

The rude behavior you describe is not intentionally sexist, but it has a disparate impact on women, who statistically tolerate interruptions more.

Often times when you think you know what they are going to say, you are wrong, putting words in their mouth.

If it's not intentionally sexist, it's not sexist at all. Sexism is discrimination because of someone's sex. Any other claim of sexism is irrelevant and a classic statistical error, the Simpson's paradox. It's as silly as saying that doctors are sexist because they prescribe more contraception pills to women than men.

> Often times when you think you know what they are going to say, you are wrong, putting words in their mouth.

Yes, sometimes, but in average the effect is positive (i.e. the communication is more efficient).

Sexism has to be intentional? You're redefining the word simply so you never have to deal with it. It doesn't even jibe with your own definition ("Sexism is discrimination because of someone's sex."). People do many things unconsciously, and systems push people toward certain actions without engaging the conscious consent of those involved (a fancy way of saying we humans often take the easy path rather than the thoughtful path).

You can certainly be an asshole without being intentional about it :) Try and argue that's not possible!

Right, "intentional" was not the correct word. What I mean is that sex has to be the primary motivator/discriminator of the action (whether the motivation is conscious/intentional or subconscious), not just a statistical artifact, as in your example with interrupting people and women tolerating that more.

I have a problem of talking over friends [in two-part conversation]; primarily because I've already established what they're saying and so I skip to my turn - mostly I can catch it and slow down the conversation on my end to match their pace of delivery.

It's kinda like when I can't remember a word, or a person, usually my wife - or a close friend - will have established who it is or what I'm talking about, the word doesn't need filling in to convey the meaning to that particular person.

It also turns up with acquaintances who might broach a topic I'm familiar with, they take a slow pace to allow me to follow - but interrupting demonstrates I know what they're on about and allows them to up the density of the conversation. I see this as beneficial; others detest it I'm sure.

>Stopping people talking over others makes life better for everyone //

Why let someone gabble on if the whole group already is at that level of understanding on the subject though; is that really better?

Well, if I'm going to be a poor culture fit anyway, it may as well be on my terms.

That puts them on the defensive. Very very bad.

How about "Theres a lot of tension in this room. Is something going on?"

I once had an interviewer intentional preface with "I always come off a bit hostile" and I was tempted to just stop right there. If you appear hostile in interviews and you know you appear hostile in interviews because people keep telling you that, why are you even still in the interview loop? Technical interviews are already stressful enough without the added stress of a hostile inverviewer.

Yeah, that's poor wording on their part. It would be better to say something along the lines of, "Let me know if I get too aggressive - sometimes I really get into these whiteboard problems and I appreciate your feedback."

In this particular anecdote it didn't appear to be aggressiveness that the interviewer could control so much as a social cue/interaction issue of some sort (possibly autism-spectrum) presenting as brusqueness/disinterestedness. (Of course, that's giving said anecdotal interviewer the benefit of the doubt, because it certainly came across, at its worst, as general rudeness and an impression that even performing an interview at all was a waste of that person's time and effort. If that were the case it was even more a question of whether it was a good idea that said interviewer should be involved in interview loops.)

I realize in software we have to deal with plenty of people on the autism spectrum and/or with various sorts of social skill deficiencies, but technical question whiteboarding has enough difficulty that you probably don't also want to throw in such a difficult social interaction test in the same interview. (Not to mention that some of these social interaction/spectrum issues can lead to pedantry in a technical interview that maybe biases the technical interview in a poor way.)

I can't say I'm surprised. I've done my fair share of interviews before I was 30 and while I never cares about age I had several colleagues who would come to grab my for my turn interviewing and comments like "old guy in room 1 is ready for you" always made me think they viewed them negatively.

Though bias is hard to shake. I'll admit I have some bias against PhD holders interviewing for engineering positions. Almost every single one I've ever interviewed couldn't even do very, very basic coding but could talk lots and lots of buzzwords so it kinda wore on me and it was hard to not go into an interview starting with a negative view if I knew they had a PhD.

I feel like I still gave everyone their fair shake but it was hard to shake that feeling.

Interesting… Why do you expect that a Ph.D. would necessarily be an above average coder?

Initially, before interviewing anyone, I kinda assumed a PhD candidate would be on par with other developers as far as coding goes (so not above average but also not below). But in my, only anecdotal experience, I actually haven't interviewed one yet who can do basic coding. That isn't saying PhD holders can't code or that even the majority can't code; only that those few experiences started to shape my own bias going into an interview viewing them as already negative.

Like any person I have biases but I feel like I did well not to let them affect the course of the interview and ultimate outcome it was just a feeling shaped by my limited experiences.

I think your conception of a Ph.D. is off by quite a bit. Outside of their dissertation topic I'd expect a Ph.D. to be on par with an undergraduate, from the time period they graduated.

You also said that you're hiring for an engineering position, but you seem to only care about coding. Perhaps I don't know what you mean by engineering, but I'm under the impression that there's a lot more to engineering than any single skill, even by the loose SV definition. How do your Ph.D. applicants do outside of coding?

> I think your conception of a Ph.D. is off by quite a bit. Outside of their dissertation topic I'd expect a Ph.D. to be on par with an undergraduate, from the time period they graduated.

Maybe? Maybe not? I've had very mixed experienced in interviewing folks where some had zero college and could code amazingly, great at solving problems, etc and I've had the exact opposite. I'm not convinced school education is any type of [significant] indicator for coding and problem solving at this point.

At least this is what's happened in my own experience hiring. Not sure if there are any good studies done in coding proficiency and problem solving versus education (though I could see those being hard to measure well).

> You also said that you're hiring for an engineering position, but you seem to only care about coding. Perhaps I don't know what you mean by engineering, but I'm under the impression that there's a lot more to engineering than any single skill, even by the loose SV definition. How do your Ph.D. applicants do outside of coding?

Well, software engineering involves reading and writing code so that's a huge part of it with the other part being problem solving. Really the problem solving is the most important part, the rest can be taught with time. But essentially we had some very, very basic coding questions (not even trick questions) just to get an idea where the person was as far as their ability to write code. We didn't care what language(s) they knew (they could pick) as long as they could demonstrate some basic knowledge of coding and then problem solving.

Since we were hiring for software engineers, if a candidate couldn't write code in any language they were simply not moved to the other interviews. Not much we can really do there.

Speaking as a Ph.D. (not software or computer anything but traditional engineering), I think you're conception of what a Ph.D. signifies is very wrong, and it's leading you to improperly value what advanced academic training is worth.

Software engineering encompasses the SDLC, which includes a lot more than coding. What about documentation, quality control, or formal methods? There's many roles that I would expect a Ph.D. to be likely to perform well in, more so than someone self-taught. Seems like you're ignoring the bigger picture.

I think we programmers tend to see coding as akin to reading, if you can't code you don't even get the chance to get into other stuff because you're missing the most basic skill of software engineering, the ability to make a computer do what you want it to do. No one interviews for "software engineer" and wants someone who can barely code, writing code is virtually always the number one requirement of the job.

If fact when I hire, I require a small programming project be completed (simple, save some objects to a file and read them back out passing this unit test), that is the resume, if you can't code I won't even look at any other credentials. Rookie programmers with only a few years experience often do far better at this task than people claiming a decade of experience. The most experienced people often completely fail the test.

> I think you're conception of what a Ph.D. signifies is very wrong, and it's leading you to improperly value what advanced academic training is worth.

The job requires being able to develop software. Candidate, who holds PhD, cannot develop software despite being a CS grad. This isn't charity; what would you prefer I do when I get such a candidate? I saw two PhD holders like this which, yeah, could be a HUGE minority but I'm being honest about how anecdotes can create bias and I also mentioned that I felt I did a great job not using my bias against them (we all have bias, remember).

Not knowing the language we use in house? Not a big deal. But if you can't demonstrate fundamental understanding of code structure in any language I'm sorry but I do not have the budget to educate you. I wish I did sometimes; someone who has awesome problem solving skills could be an amazing developer.

> What about documentation, quality control, or formal methods?

No offense but when shit hits the fan, none of those matter. At all. Unfortunately. Plus I think it's good when you make developers think about and do as much of the documentation of their own code as possible. Sometimes seeing it on paper can make you realize "hey, this is too complex to call; I think I can simplify!". At least in my experience anyway. QA / QC, yeah separate group is idea but rarely doable depending on your industry.

> Seems like you're ignoring the bigger picture.

Again, business is not a charity. Big businesses or academic arenas can afford more things but start-ups / small companies? Anything that isn't moving the product out the door gets slowly trimmed away as margins get leaner. It's far worst in the government contracting space where you're legally allowed to only have a certain amount of margin.

A PhD program basically produces a researcher who is the world's expert in a very very narrow area of a subfield. As a job candidate, a PhD holder could offer, in descending order of "putting their degree to use", A) their subfield specialty, B) their ability to work as a researcher, C) being a smart human.

If you're interviewing a PhD for a nuts and bolts software engineering role, you are basically hiring on the basis of C, ie their degree is a dubious value add for you. PhDs are rarely going to be an ideal hire for a startup unless their subfield is literally the core of your business.

As an aside, I am bewildered by the the idea of a CS PhD holder who literally cannot code in any language. But short of seeing their CV, who knows. Maybe they specialized in the more theoretical math- or EE-like areas of CS, and their undergrad data structures course was a distant memory?

> As an aside, I am bewildered by the the idea of a CS PhD holder who literally cannot code in any language. But short of seeing their CV, who knows. Maybe they specialized in the more theoretical math- or EE-like areas of CS, and their undergrad data structures course was a distant memory?

One mostly did neural network research and said his coding was rusty so he has having issues. The other I honestly can't remember. But yeah I'd assuming coding was pretty important but I kinda got the impression from both of them that maybe they had underlings do the grunt work or something. But not entirely sure.

> I think your conception of a Ph.D. is off by quite a bit. Outside of their dissertation topic I'd expect a Ph.D. to be on par with an undergraduate, from the time period they graduated.

Aside from dissertation research, my understanding was that Ph.D programs usually include substantial graduate level coursework in the degree area (at least equivalent to or expressly including, Master's degree level work), so they should both have greater currency and greater education, even outside the specific narrow focus of their dissertation, than an undergraduate. The degree to which this is job-relevant, of course, may vary.

It is a familiar comment that Ph.D. holders cannot program. I have a Ph.D. and I dare say I can program. I was offered a position by Google recently so I am above some threshold. It is really unfair to paint a broad class of people with such a sweeping brush. I find that people often overestimate efforts required to attain a skill level, probably due to human nature to elevate one's own skills or importance, or they unconsciously conflate familiarity with general intelligence. It is impossible to reinvent collaborative filtering within 45 minutes without any prior exposure if not told any reason behind or constraints under which collaborative filtering was invented. Software engineers ask basic questions from the narrow fields they operate in day in and day out and believe that the interviewees have all requisite knowledge and answers should pop into their heads. On the contrary, basic questions are often fundamental innovations and it is no small feat to come up answers in the first place. It is a hallmark of a real intellectual to probe deeper and learn from that experience and realize insights and reasons for reaching innovative solutions, so that next time he or she will be innovative quicker or better.

It is hard to accurately judge someone in 45 minutes. I made a mistake with fizzbuzz three years ago when interviewing with the hacker school (now called recurse center), so what? It isn't I cannot do it but that I was looking for better ways and not finding it. After reading that there is no shorter way than to enumerate all four possibilities I was able to mentally unlock. It took just a few months of studying example code and discerning coding patterns for different logic control flows and now multiple programmers have commented that I write readable code. Anyone who has worked through real analysis problems can reason through most code well. It is a matter of concentration and time. I firmly believe programmers can make good ML engineers even though I spent years on numerical linear algebra, mathematical programming (optimization), statistics with measure theory and I still feel I have huge gaps in knowledge. So what if someone doesn't know a basic theorem, as long as they can learn enough and apply it to do their job. We take people as they are and help them grow into roles we want. I hope you will give everyone a fair chance.

> I hope you will give everyone a fair chance.

I certainly do / did (haven't done hiring in about a year now). I'd like to think I'm very analytical and put the person above any bias I have I just wanted to share how I thought it was rude to be bias against older folks and then I was doing it myself going into an interview with someone who held a PhD.

In the end I didn't let my bias get the better of me but that type of instinct, regardless of how inaccurate it may be, is tough for anyone to get over and everyone has them about something.

If you were as good at analysis as you say, you'd have recognised that the parent took pains to state their opinion is formed from personal experience, is caveated with 'almost all', and recognises their own resulting bias, labelling it such. It seems to me that you're projecting your frustrations on someone who doesn't deserve it.

Ironically, the parent complains of PhDs using lots of buzzwords (meaning using language as a cover), and your defence is full of long wordy phrases.

Edit: To clarify further, if you're going for a job, your ability with words is less important than your ability to solve presented problems. People are hired for solving problems, not for trying innovative solutions just for the sake of it. As an example, upthread there is a person complaining that one of their hires spent two months doing a project in a language no-one else in the company knew. An innovative solution, but bad for the company, because it leaves the 'maintenance' part of the problem unsolved.

A negative view of PhD holders seems to be confined to the Valley. I am far removed from the Valley and all the PhDs I work with are some of the more brilliant people you'd ever meet. Great at their job. Extremely innovative.

And yes I call them Dr. So-and-so and no they didn't insist I call them that or anything. I just automatically address them with their title as a sign of respect. If they say "oh call me John" or whatever then I'd adjust accordingly.

I am turning 40 in a year and almost everyone I work with is 15 years younger than I am. My opinion is that you have it all wrong. I don't think younger engineers are hostile to old age, but culture fit is important. It's not about your age but how you carry yourself. Until you're in your 70's you can probably afford to make an effort to understand the culture of 20 somethings. You can look to speakers at tech conferences and many are probably as old as you and I but don't have any problems fitting in with their younger peers.

You just have to be willing to adapt yourself to fit in with who you work with. If you aren't interested in making personal changes because you shouldn't think you need to just to earn a paycheck then well you're probably not a good culture fit. You need to make an effort. I enjoy the same things my peers do, we play the same games, we watch the same things and read the same websites. It's not fake with me. I'm not trying too hard. I'm just not getting stuck in old ways.

Culture is based as much by the outliers as it is the core group. Also experiences/opinions offered by those outliers can be quite useful to avoid the herd mentality.

I've seen too many folks rejected as "cultural mis-matches" not because they don't get along with everyone else, but because they have different interests outside of work. That's just silly.

Maybe that isn't all the inaccurate of a dismissal, if the culture there is work to the bone, then somebody with non-work interests would certainly not enjoy the culture there. Not saying that I endorse that kind of culture, just that "culture mis-match" might just be the most accurate statement at that point.

Most accurate, perhaps, but also quite likely the least relevant statement. You're not looking to move in with them, after all.

If you'd like a really simplistic example of why that form of culture just doesn't matter, have a look at Adam Savage and Jamie Hineman(sic). They have never even had dinner together, yet they make for a very effective team at work.

Penn and Teller are also known to only be business partners and don't communicate outside of work. They are however extremely successful and prolific.

Then come out and say it.

I'd be all for the phrase "culture mis-match" being banned. If you can't properly articulate why you don't want to hire someone, then the problem is with you, not the applicant.

"I don't think younger engineers are hostile to old age, but culture fit is important."

I'm pretty sure that is basically the definition of age discrimination people are facing. Its the same line given for other groups. This fascination with cultural fit which is basically group think given your examples (e.g. "I enjoy the same things my peers do, we play the same games, we watch the same things and read the same websites.") is disturbing and reminds me a bit too much of high school not business where experience and talent applied to implementation are important.

> I'm pretty sure that is basically the definition of age discrimination people are facing.

Age discrimination is based on a fact you can't do anything about, your age. A company's culture is very important, a vital aspect of its identity. If you aren't open to making a change then you probably don't belong. Anyway, a lot of things people my age and older like are just the things 20 year olds liked when they were 20.

Let's review a second so I can understand something, how does "I enjoy the same things my peers do, we play the same games, we watch the same things and read the same websites." equal a company's culture? The HP Way is a company culture, what you describe is a social club.

Many companies--especially tech companies--deliberately blur the line between those two things.

I'm starting to get that. They don't seem to want a company cultural. It really seems like they want a posse or fraternity. When you look at it that way, of course anyone outside a very narrow demographic is unacceptable.

Why does the image of a party of wizards that forgot to bring the fighters, clerics, and rogues come to my head?

Bull, if you can't get along with a wide range of people then you have a problem. I get the nerd stereotype of awkward introvert, but we, as working adults, need to deal with it.

> "A company's culture is very important, a vital aspect of its identity."

Is everyone being super-stoked about Star Wars and Breaking Bad really a vital aspect of a company's identity? Is a shared passion for ping-pong over lunchtime really an important part of a company's continued success?

In my personal experience, I've learned a huge amount from coworkers with whom I had very little in common besides the shared dedication to shipping great product.

Here's my challenge to everyone on HN - "culture fit" isn't intrinsically a bad thing, but the term is vague and encourages all kinds of intellectually dishonest cowardice.

Stop using "culture fit" and instead use specific observations. "This person has poor hygiene" is a valid observation, "This person defended some really bad code despite reasonable criticism", "This person was openly hostile to one of the interviewers", etc.

"Culture fit" is a weasel word that is vague - sometimes intentionally so - and largely useless. Specify why someone is a bad culture fit with concrete observations. And hey, sometimes when you are specific to yourself you'll find problems in your own thinking (e.g., "This person totally glazed over at the pop culture references I made." doesn't even begin to pass a sanity check, but accounts for a lot of "bad culture fit" decisions).

I was going to comment something like that. He doesn't like Foosball - we can't hire him! But maybe "culture fit" means willing to work huge irregular hours. "old people" with a family probably won't go for that. As a developer I always try to avoid crunch times by planning ahead - guess I am "old".

> Is everyone being super-stoked about Star Wars and Breaking Bad really a vital aspect of a company's identity? Is a shared passion for ping-pong over lunchtime really an important part of a company's continued success?

This is a different argument than one about age discrimination. Whatever the culture a company and its employees adopt, my point is that it isn't necessarily age discrimination if you are getting the "not a good culture fit" feedback. It's not the number of years you've been alive so much as an attitude, which is something you can change. If you're unwilling to, fine. If this makes you mad, I'm sorry. However your emotions sway you, it is still not age discrimination.

But depending on how stringent your bounding box for "culture fit" is, you end up building an archetype for age, gender, education and ethnicity of your target employee.

The point is is that if you're targeting people who behave like you, have plenty of shared interests and reflect your own way of doing things, those people are going to end up looking a lot like you too.

I think the point that potatolicious is trying to make is that the ambiguity of "cultural fit" ends up becoming a path to hiring people who are very similar to yourself. An alternative approach would be to define explicit, concrete values that your company and team reflect, and look for hires that mirror those values instead of nebulous "cultural" fit.

>it is still not age discrimination.

The law may not agree with you. Ever heard of disparate impact? "In United States anti-discrimination law, the theory of disparate impact holds that practices in employment, housing, or other areas may be considered discriminatory and illegal if they have a disproportionate "adverse impact" on persons in a protected class"

People over 40 are a protected class in US employment law.

Now, policies that can adversely affect a protected class are ok as long as there is a legitimate job requirement. For example, being able to lift 50 pounds may be a job requirement that adversely impacts women and the disabled but its ok as long as the job actually requires heavy lifting on a very regular basis.

Otherwise people are free to implement policies that are code for discrimination such as "able to lift 50 pounds" for a desk job.

You'd have to prove in court a legitimate job requirement. I think proving" likes ping pong and beers after work" being a businesses concern may be an uphill battle even if you call it "attitude."

Once you realize your hiring practices may exclude a protected class you really gotta do a second look over and ask yourself if it is really a business requirement. Other shops are able to ship products with more diversity and less ping pong.

I would say that it is reasonable to assume the "not a good culture fit" IS discrimination until proven otherwise.

And once again, with the supposed shortage of engineers, why isn't the company adapting?

If everyone likes Star Wars then you can make Star Wars references and jokes in company meetings and announcements and expect positive reception. Any effective presentation requires a knowledge of one's audience. But it does seem kinda backwards to pick the audience based on their fit for the presentation rather than adjust the presentation to the audience.

At my present company the upper management is constantly trying to make jokes that the 20-somethings will get. That includes movie references and things which you know some of them don't really get (especially when they say "I'm told you all will find this hilarious"). It shows a willingness of those older, experienced people to adjust their presentation to the "culture" of the current employees. The overall culture of the company is still to have a lot of fun, just the jokes change a little as time goes on.

My current company's founders (and don't even get me started on that) love Star Trek. They use it as street-cred of their zaniness and quirkiness and geek-cred. It's used in company literature, it's used to make jokes, and it's foisted upon new hires as though it's actually important.

We apparently care more about Star Trek and culture fit than we do about writing maintainable code, selling product, or anything else we don't talk about much.

I now hate Star Trek (and I used to like it). :( :(

Well, to be fair, someone born in the early 70's or late 60's is probably more stoked about Star Wars than any 20-something.

After all, they grew up with the series.

Not among my friends born in that time frame. The whole prequels put me in the "fool me once" category, plus its J.J. Abrams who already destroyed the Star Trek we grew up with. If it gets good reviews, I will see it, but I don't know anyone who is stoked to see it.

For what it's worth, I enjoyed the new star trek series... The only thing that made the newer star wars prequels worth watching were yoda fight scenes.

Shared experience is good for communication. Disparate experience is good for learning. A star wars joke can cut a 20 minute discussion to zero, just because "That's great kid, don't get cocky", communicates what might take quite a while to express.

It's a really delicate balance. "culture" can mean speed. I don't know of many organizations that do this, but it's certainly possible. OTOH, that locks you into a specific worldview, and can make you blind to problems. Diverse backgrounds make organizations much more aware, but less able to communicate that information quickly.

An example is when someone picks up a new language, and they try to explain the new constructs and philosophies behind the language. It takes a long time to explain why mapcar is cool.

Seriously. I used to enjoy Star Wars, Breaking Bad, LOTR, ping pong, etc. After working in this industry a few years I'm thoroughly sick of all of them.

At this point, for me personally, nerd culture in general can go fuck itself. It's just no fun anymore now that it's more or less a job requirement.

Culture fit is often just a euphemism for "we don't like you for a reason that would be illegal to state directly due to discrimination laws". A reason such as you're too old.

When did you ever have a company state any reason for not hiring you?

I could have worded that better, it's not what's stated to you, it's what people say when they talk about not hiring someone to other people they know, such as those talking about it on this board now. It's a nice little lie people tell to avoid admitting discrimination of some sort.

Emphasis on the phrase "culture fit" tends to go hand in hand with cultural and racial homogeneity in my experience, too.

It's interesting how many red flags a company can throw up so quickly. Often before you've even finished browsing their website.

I think "culture fit" here is a replacement for: "He isn't young and single and probably has a family, therefore he won't want to work 70 hours a week and stay in our awesome fully stocked with free soda and snacks office 24/7 and instead actually go home after normal work hours, and we can't have that."

Yeah, that too. It seems to function as a placeholder for any reason the interviewer might be ashamed to admit in polite company.

Not all companies are like that. We put a huge emphasis on culture fit but it's nothing like what you suggest. We've gotten far more diverse as we've grown.

What is your definition of culture fit then? Be specific about traits which are indicative of a good or bad culture fit for your team/company in particular.

Is this person going to be goddamn annoying to be around 40-45 hours a week? (Oh, how this has happened.)

Does this non-medical phd demand to be addressed as doctor? (Yes, this happened.)

Does he or she seem willing to do his or her share of the scut work?

Is he or she a failed academic who is getting an industry job and going to be a pain about it, or is this what he or she wants to do?

How much supervision does the candidate require? Initiative? If he or she runs out of work, is he or she going to to sit there and do fuck-all until I notice or will the candidate be proactive about getting more to do?

I understand some of our code is under tested, but unlike TDD wankery, there is a real business cost to spending a bunch of time writing tests and, since those systems are either mostly finished / slowly changing, or on their way out, is this candidate going to be difficult or suck it up and deal? (Yes, this happened. See also scut work and/or the realities of living in our fallen world.)

We've made a decision to standardize on scala/java and js/some frontend package I'm not sure of. I understand this isn't react or the new hotness; does this candidate seem like he or she will throw a fit then spend two months working on a service in a language nobody else uses (yes, this happened. And he was surprised when he was terminated. There were other issues but this was the proverbial straw.)

Hygiene. This should go without saying, but apparently I am cursed. If I can smell you in an interview, we're done. (And yes, this has happened.)

One more set of edits as the bad memories come back:

You look at my two female data scientists and a female engineering peer and the one female office manager and ask why there are so many secretaries working here? Yes, this happened.

You call one of my female directs "sweetie." Yes, this happened.

We're talking on the phone and you couldn't be arsed to spend 10 minutes on our site and come up with a 1-2 sentence summary of what the company does. You can be wrong, but you must demonstrate minimal interest. And to be clear about the level of detail: if I were airbnb and you said platform to allow people to rent out their homes for short stays, that would be awesome.

I don't think any from that list is really cultural. They range from basic professional behavior to basic polite society behavior. I've run into people with the hygiene part. I've dealt with farmers who have just dealt with their pigs that smelled better than some folks I've encountered.

Also, "sweetie", really? When I was younger (teens) I offended someone by saying "Ma'am"[1], but I'm pretty sure I would have took a swat to the head from my parents if I ever said "sweetie".

1) I'm pretty sure at this late date (20+ years ago), she was a bit ticked that I used "Ma'am" instead of "Miss" implying she was older than she was. I'm pretty sure she was between 18 and 20, and I was 15 and looked a lot older.

Professional and polite behavior is cultural fit :) Or at least the working definition at this and previous employers where I've been a hiring manager.

>I don't think any from that list is really cultural

It looks to me like a laundry list of requirements that they wouldn't admit in polite company or want to have documented in their company records, or advertise on their website.

They wouldn't want to put off any investors with bad breath, a PhD, or a penchant for saying 'sweetie', after all.

Also, one of the items clearly advertises an objective deficiency in their working practices. It's pretty plain why they'd want to keep that under wraps.

So yea, less about culture and more about having a list of hidden requirements.

> Does this non-medical phd demand to be addressed as doctor? (Yes, this happened.)

WTF is wrong with that!?!? It is polite to address someone the way they want to be addressed. I address my PhD holding colleagues as Dr. very often though none are medical doctors. I can't imagine how this is an issue for anyone ever.

Unless you're an MD, I'm not calling you doctor, and it's a 5-nines indicator you're a jumped up prick. In english, Dr. is a honorific reserved for MDs, dentists, and psychiatrists.

If you ever have to work in an academic setting then you will probably see a lot of folks requiring the title. It's a pecking order thing and there are rules.

I get that there's an academic pecking order around this. But I work in industry and see previous post about people who couldn't hack it in academia and want to come to industry and treat it as if it were academia. They will not work out, and I'm uninterested in having their pecking order games in my team.

If there was any confusion, I most definitely meant in an academic setting, and would not generalize my answer to other settings.

Everyone different ideas.

This is what Miss Manners says:

https://www.washingtonpost.com/lifestyle/style/miss-manners-...

DEAR MISS MANNERS: My future sister-in-law just graduated with her PhD She told me to call her “doctor,” but I was always told that if you don’t work with someone directly in their field, that doesn’t apply.

Is that true? I understand it’s out of respect, but I have never addressed other persons with their PhD as “doctor.” They also put PhD at the end of their names, teach at universities and don’t go by “doctor.”

GENTLE READER: There are two attitudes that individuals and universities take toward the use of the title “doctor” for those who hold PhDs.

One is that having been earned, it should be used, not only in professional situations when needed for identification, especially in academic positions, but also socially.

The other is not to use it — not socially, but especially not in academic positions, because that level of education being assumed, it need not be expressly mentioned. As one professor (namely, Miss Manners’s Uncle Selig) once put it, “A PhD is like a nose — everyone has one. It’s only conspicuous if you don’t have one.”

Which form of snobbery is preferable, or perhaps more effective, others can decide. Obviously, your prospective sister-in-law espouses the first-named approach. And she is covered by two rules:

1. Address people as they wish to be addressed.

2. Try not to annoy your relatives unnecessarily.

I get the feeling in my extended family that words would be spoken to the sibling to indicate that the future sister-in-law was either "too big for her breeches" or the sibling might want to reconsider the whole thing. No disrespect intended to either the future sister-in-law or Miss Manners, but family is first names or nicknames.

You're conflating personal and professional. In your private life, you're free to be a prima donna and demand whatever your family and friends will put up with. At work, you're not, and unlike Ms Manners, I'm neither your friend nor a family member that has to humor you. Demanding that people play status games is going to get you a fiat no-hire from me, in part because you will find many of the tasks beneath you. And such a person would be unlikely to tolerate calling his or her managers Mr. / Ms. X. As should be obvious, if being called doctor is a deal breaker for you, there are lots of other employers. I think you're unlikely to find many in the valley that will tolerate such nonsense, but it's a free country -- anyone can keep looking until he or she finds a company that tolerates it.

"Culture fit" in this case appears to mean "don't say or do anything, no matter how minor or symbolic, that might be construed as a challenge to my authority over you".

i.e. it's a big fat euphemism.

Just say "no prima donnas" on your list of requirements. Most people will be able to read between the lines and know that you're looking for servility, fealty and obedience in your employees. I, for one, would be happy to screen you out based upon those words. I'm pretty sure you wouldn't like me, I wouldn't like you and I wouldn't want to waste your time or mine interviewing with you. Those three words would save us both a lot of trouble.

I, OTOH, am appalled by how the medical profession has stolen the title 'doctor.' A doctor should be someone who has expanded the sum total of human knowledge by performing original research; an MD is just a technical degree.

I always refer to those who have earned an MD as 'physicians' or 'surgeons.'

When using last names, sure it's fine to insist on Dr. Smith over Mr./Ms. Smith.

But if everybody at the company is on a first-name basis but you insist on having everybody call you Dr. Smith, you're being unreasonable.

I don't think its unreasonable to request someone address you with a professional title in a professional environment.

"We're on a first name basis here" is cultural, unlike the other stuff mentioned, so there's that. But its pretty bizarre.

Would you also fire them for wearing business attire instead of shorts because "this is a casual environment?"

What you describe isn't culture fit, but not hiring arseholes. 'Culture fit' suggests traits that aren't suitable for your company, but are suitable for others. Your list is a series of bad points for pretty much any company.

> Hygiene. This should go without saying, but apparently I am cursed. If I can smell you in an interview, we're done. (And yes, this has happened.)

Just a note: sometimes this is BO caused by medication. You want to avoid saying "I didn't hire you because you smell" because that may be a result of a protected characteristic. A reasonable adjustment would be that the person has a trusted friend who will tell them if they smell or not, and will shower before they get to work and will use deodorant products.

A bit less common would be "fish odor syndrome" or Trimethylaminuria. http://www.channel4embarrassingillnesses.com/conditions/fish... You probably don't want to be cruel to people who suffer from an illness that they have no control of.

Back in high school I worked with a guy who had BO. His roommate (who I also worked with) told me that he didnt actually have a hygiene problem. Showered every day but for some reason he still had BO. I'm not sure how true that is but thats one data point.

Since some food and medicine can cause your pee to smell really weird it makes sense it can screw with the smell of your sweat too.

>I understand some of our code is under tested, but unlike TDD wankery, there is a real business cost to spending a bunch of time writing tests and, since those systems are either mostly finished / slowly changing, or on their way out, is this candidate going to be difficult or suck it up and deal? (Yes, this happened. See also scut work and/or the realities of living in our fallen world.)

I had a feeling that somewhere along the list of "candidate must not make us put up with any of their bullshit" there would be something saying "candidate must be willing to put up with a metric ton of our bullshit".

Allow me to highlight what I wrote:

   either mostly finished / slowly changing, or on their way out

Most of those old systems support a part of the business that is dying and are maintenance only, but occasionally they do need some extra duct tape. We minimize any investment at this point. At this point it's a day or two of work a month spread across a team, but everyone takes a turn.

I don't see the point. Either shut it down completely because it's not worth the investment to maintain or do it properly.

Test driven development is a practice that is most valuable on legacy code. Only doing it on new code and not old code is ass-backwards. If anything it should be the other way around.

A half assed hack job to support remaining customers will likely only end up alienating them when you inevitably break stuff they rely upon with duct tape. Alienated customers tend to drop you forever and run into a competitor's arms. YMMV but that's always been my experience.

The point is money. It shouldn't be hard to imagine a business that is earning money but will never again grow, is worth no further investment, and is therefore being run out. I reread what I wrote; you appear to be deliberately obtuse.

fit the culture is just pc phrasing to dodge hiring issues. its a cover, nothing more. some people saying it may believe it to be a true concern but its just code for "we don't want your type"

Indeed, I find it a big red flag when I hear mention of "efforts" to reduce homogeneity. Frankly, any mention of any "social engineering" terms is a big red flag for me.

The only thing that matters is professionalism, work-ethic, and skillset (and my personal favorites, politeness and personal-space respect).

Age, race, gender, nationality should not matter in any way for hiring decisions. But then again, I fall into the "leave it be" side of human freedom and anti-discrimination efforts, rather than the "let's meddle and try fix it with reverse-effects" camp.

People who are all alike tend to have the same blindspots. If you have a group with different POVs, they can more easily catch things that others might miss. Race/gender/age/&c.-related blind spots may be more important in some domains than others, but these blind spots are very salient in a wide variety of places in American life.

Focus on cultural and racial diversity in my experience tend ignore age as part of diversity. Lets not pretend 'they' would actually give a fuck about older developers.

Here is a "diversity team" http://diversify.github.io/images/diversify-group.jpg

Beware of hypocrites abusing "diversity" for PR reasons.

I was a bit shocked by that photo until I went to the page itself at http://diversify.github.io/ and read:

> Diversify was a weekend event at Spotify in Stockholm, where 40 tech students of diverse backgrounds came together and designed, wrote code, and found new friends.

Maybe having students to this is in part pointless, but that picture is not of a group of Spotify employees working on diversity issues.

It's interesting that you bring up 'group think.' I immediately thought of my back country avalanche training and how deadly 'group think' can be when I read your comment. I wonder if organizations built around a 'cultural fit' are hurting themselves in the long run.

Diversity isn't about making personal changes to fit in with a group that is different than yourself.

You might not sense anything at forty especially if you're one of these youthful "40 going on 27" types, and the mid 20's people pretty much accept you as one of them. People's stereotypical ideas of what forty looks like doesn't match all the examples of what forty actually looks like.

> You need to make an effort. I enjoy the same things my peers do, we play the same games, we watch the same things and read the same websites

I really don't see why colleagues should read the same websites or play the same games! You can have a very good work relationship with someone that has a totally different lifestyle.

I'm 40, and this year I finally feel the pressure. I grew up in a world without google. My first instinct is to figure out a solution to the problem - and it's really hard to break that habit.

Although the strategy had served me well for a very long time, it just doesn't work these days. What's more important is one's ability to be resourceful - to google the quickest.

I don't mean that as a negative - some of these 25 year olds just blow my mind with how fast they can find the right code snippet that they need and integrate it using specialized IDEs. It's not that I can't do it, it's just not a skill that I have strength in. And, in a way, I doubt I can gain it.

The squeeze comes from salary and title. At the top of the pyramid, it's hard to gracefully slide down. This is a world where it's up or out.

> I usually sneak in a couple of technical questions for the interviewer and he blew those questions

That's interesting, how do you ask technical questions to interviewers without being too direct? I am genuinely curious about it.

Just ask how they would do X. They'll either be appreciative of your engagement, or appreciative of an opportunity to show off. Never fails.

I momentarily "forget" something that's only tangentially related to the problem at hand. It's usually something like "I've been working primarily in the new (or beta) version for the past three months, do you remember if you could do it this way in the current version, or is that a new feature and I have to do it this other way?".

The trick is finding something minor but indicative. Things related to testing frameworks or immutability are usually good IMO. Things that are incredibly important to good devs but afterthoughts to medium-level devs.

Lately, I've been asking about C# read-only autoproperties, which just came out 2 months ago. That's a really minor nano-feature in and of itself and sounds like an overly-technical syntax aside, but if you're a c# dev and you care about immutability then the lack of that feature was a constant annoyance and you would be intensely aware that it wasn't possible. So if you just don't know or don't care, that tells me something about what's important to you (The usually caveats about ensuring exactly what is the interviewer's primary daily language apply, but that's usually easy to determine).

I'm a C# dev and I had to lookup this new feature since it didn't ring a bell. I'm curious, why is this is a big improvement of just having "private set;" in the auto-property? I'm not being sarcastic, I genuinely want to know.

(Incidentally, in terms of your filtering, I absolutely categorize myself as a "mediocre" or "medium-level" developer, but that doesn't mean I don't care about things. Just that their value may not be immediately obvious to me.)

With private set; you still have to invoke the setter in the constructor. For some cases, it's more readable to have the value of the property calculated in the same place that the property is declared.

Also, when reading code, private set; doesn't guarantee that the property is reassigned elsewhere in the class. You have to read the whole class to verify that.

It is actually the equivalent of a private backing field that is marked readonly.

  public class Person{

     private readonly string name;
 
     public Person(string name){
        this.name = name;
     }
  }

It's syntactical sugar that shaves a few lines of code off, particularly if you aren't setting values from parameters in the constructor and just want readonly values that are inherent to the class.

readonly means the property is immutable. It can't be changed after construction, period. "private set" suggests it can be changed at any time, but only privately.

Like I said, it's a small item, but if immutability is a primary concern to you during class design, then typing that "private set" constantly (or alternately, using a backing field) annoys you just a little bit multiple times a day. You're acutely aware of it and its workarounds.

Most devs, even most "advanced" devs, don't think about immutability that much. I would never dream of using this as some kind of hiring filter when hiring devs, it's too obscure. But if I'm on the other side of the interview chair, I find it useful to know if your top devs, the people you rely on to evaluate others, care about things like that.

OTOH, in practice, I think the question turned out to be not nearly as useful as some of the testing questions I've asked in the past.

Actually, I would use that technique of mentioning a cutting edge or rarely used feature of a language, not to discretely test the interviewer as he does, but to show off my knowledge and redirect the conversation on something I will be familiar.

I sometimes 'ask their opinion' on taking a certain approach when there's a right way and a non-obvious trap.

If they get the question right they'll feel smart for a second and it gives you an opportunity to bond - you can laugh together about the idiots who did it the wrong way.

If they get the question wrong they're usually oblivious to it. Opinions can't be wrong, right?

> keeps trying to push you in bad directions (inheritance over composition, singletons, etc.)

I hate to say it, but this kind of direction is also pushed frequently by inexperienced developers. It is also frequently made worse when they feel they have to prove their ability to developers with more experience.

Just the other night I was having a conversation with colleagues from a side project - one is the CTO (he made the position a stipulation of employment when the founder was starting this side project), the other the founder, and I was trying to convince them both why deep inheritance and "shaking the tree" with every code commit creates code maintenance problems down the road.

Unfortunately, the inheritance model was the CTO's design (after all, the data has very strict hierarchical relations, right?), and the only real answer I got to justify his plan was "so there's nothing technically wrong with it, your objection is purely fear based; keep tabs on that fear and let me know how it goes". I was concurrently scolded by the founder that "I'll never make deadlines, so you'll always have plenty of time to refactor the codebase". Needless to say, they decided that it was best for the development group to go forward with the deep inheritance hierarchy.

So yeah, the lack of experience definitely inhibits communication, particularly when you disagree with them based on your experience.

> "so there's nothing technically wrong with it, your objection is purely fear based; keep tabs on that fear and let me know how it goes"

Wow, that seems quite patronising on the face of it, are they interacting in this way to get you to keep your distance?

> "shaking the tree" with every code commit

Out of interest what do you mean?

I'm guessing it means, with a finely-sliced tree of classes changes to any class usually changes the others in the tree. Changes are chased up and down the tree. E.g. adding a new parameter to a Read() method may require refactoring APIs at all levels.

> Out of interest what do you mean?

"Shaking the tree" in this context means re-building the entire inheritence model when a new object is added to the tree. Any time the new object is not a leaf node, or it requires behavior from two non-direct ancestors, the inheritance tree must be "shaken" to re-order the inheritance such that the new node gets the behaviors as its ancestors, while avoiding things like diamond inheritance.

The (overly simplistic) example is placing the platypus in the inheritance tree to account for its characteristics in common with two otherwise distinct parent classes (birds/reptiles & mammals).

I interpreted "shaking the tree" to refer to how sometimes, when shaking a small tree, you end up with more things falling out than you expected.

I suspect they mean that changes which one might expect to be small and well-contained end up requiring touching your class (to add a parameter), your superclass, your superclass's superclass, and then all of the tests that depend on the superclass being a certain shape.

I know I've encountered this, in several projects, so I'm not sure if it's a product of poor design (possible, I wrote some of them! ;)), or merely a side effect of a complex system. I know that lately with React, I've been having similar issues when composing things (and adding new features), so that I can pass callbacks far enough down, so it's definitely not solely related to inheritance.

Yup, it occurs any time you have a strictly hierarchical relationship between objects. Module imports, classic inheritance, display containers... all suffer from this potential problem.

There's nothing technically wrong with them, and so long as you have the time to add new behaviors at the correct level and re-order the hierarchy accordingly, everything goes swimmingly. The problems arise when deadlines loom and you don't have time to identify the proper location in the hierarchy for a behavior (let alone code it), or when new members of the team don't have the knowledge of the code base to identify the proper location, or when the codebase gets too large for any single person to know where the "best" place is for something to exist...

It boils down to a human problem. And since all of our developers are humans...

"... keep tabs on that fear, let me know ..." meaning, hold him accountable when the problems arise. I consider that a healthy response: he wants you to keep questioning him!

"Shaking the tree" i.e. commits in the middle of the hierarchy will make long and broad affects in the codebase.

> "... keep tabs on that fear, let me know ..." meaning, hold him accountable when the problems arise

The actual quote was '... let me know how that goes.' That is not the positive statement that you're trying to spin it as. It is dismissive and condescending.

As far as I can tell the text is in fact "how it goes" can you show me where this is contrarily indicated?

If you're unable to articulate any arguments to support your position other than "experience", I can't blame them.

On the other hand, if you did but they were unable to understand or unwilling to listen, then I cannot fault you.

Very interesting. I'm 25 and last year, I had a similar experience with two much older interviewers. I was getting pretty hostile vibes from one of them, and he at one point gave me a problem with many possible solutions, of which my whiteboard program would print one.

Then I was asked to modify it to print all possible solutions. When the second interviewer verified that it would work as expected, the other guy was like, "but you never used list comprehensions in that." -- I threw in a list comprehension to satisfy him (although at this point, I'd started questioning the worth of all this). Next, I was told that I'd used a (max 10 element) list for random access of items instead of a dict, and that "he'd never do that". At that point, I lost it and said some pretty blunt things to him. Of course, I was rejected.

I don't know about other countries, but big services companies in India have a lot of incompetent senior programmers who simply hate any kind of opposition to their authority, and you simply have to blow them to survive. I am fortunate to have never worked at one of these companies.

There's at least some level of tenured and management defending their privileges at any company. I was momentarily shocked when in a conversation with some managers at Apple who responded in a rather hostile manner about being too young to merit a window office. Yeah, I know they are limited, but it was the instant smack-down way of saying it that told me he was trying to make sure everyone knew not to even ask.

At my current company a lot of things are based on tenure. Not the same as age, but at least slightly correlated. Sure, you gotta base it on something, but I would prefer it include more merit-based advances. (The reason for it, I think, is that this company hires swarms of recent graduates which tend to leave after a year or two, so basing things on tenure encourages people to stay longer. I'm not fresh out of college so sometimes I feel insulted by this. But they also don't have stock options which is the usual method for keeping people around.)

BTW, I'm 30 and definitely in the upper percent age-wise of people working at this company. And with nearly 3 years I also am in the upper 25% of tenure on my team.

>> big services companies in India have a lot of incompetent senior programmers who simply hate any kind of opposition to their authority, and you simply have to blow them to survive. I am fortunate to have never worked at one of these companies.

You seem to have strong opinion about senior programmers in big IT services company in India but you never worked in any of those. I served a stint in one of these and was surprised how talented some of the older technical folks were who also possessed domain expertise. Of course you won't find many but generalization without first hand experience is not fair IMO.

> ... generalization without first hand experience is not fair IMO.

Totally agreed. Maybe I went a bit too far there. Of course there are some brilliant people in those companies, no doubt. I have interviewed at a bunch of them, and I don't see why a company would not send some of their best programmers to interview people.

Am I the only one who finds it crazy that at age 50+, ostensibly after working in the industry for at least a couple of decades, a candidate would be subjected to inane technical interviews and useless whiteboarding exercises?

I understand that folks have to do what they need to do to stay employed, so opting out isn't possible for everyone, but this is pure insanity.

No, you're not crazy at all. My last technical interview(1) was the final straw. No one cared about my knowledge and experience which was actually a specialty in what the company was doing. Someone would enter the room, immediately ask for an irrelevant whiteboard exercise then leave. Rinse and repeat. I felt about 2 inches tall when I left and decided that I had to stop being a software professional if this is how it was.(2)

(1)I hate that coinage as it's no longer a dialog, but a combination of hazing and interrogation.

(2)There's also the meta-issue that if my work life is dedicated to arguments about git and inheritance philosophy, then I needed a new career.

Sounds like a Google interview

It wasn't. The Google "interview" involved being asked to regurgitate Linux header constants from memory.

Sounds fun. My last one (and probably my last one) involved being asked about inode structure in ext4 from memory.

This is such a serious problem.

It took me a long time to understand why this happens. I remember going through the interview paces at a small company where I had a specialization I knew was very valuable to them. Instead, it was all technical quizzes, tree traversal, outer joins, swap two integers without creating a third integer, find the long term state probabilities in a markov chain. I remember thinking, wow, yesterday I was doing a demo of a large, mathematically involved supply chain system to clients at a huge manufacturing company, and here I am, getting paraded from room to room, where recent graduates are asking me how to find the least common ancestor of two nodes in a binary tree.

There are a couple of factors going on here. First, a lot of big companies are in a state of constant recruitment, and they aren't really sure they know what they need you for. All they know is that if you can find the least common ancestor for two nodes in a binary tree, adapt merge sort to manage a search where there isn't enough memory to hold all the data at once, and prove that the dual of the primal is the primal of the dual, and you seem normal enough, then they'll have something for you.

The other problem is IP - perhaps they view it as inappropriate to ask too much about what you're working on.

Part of this problem flows from something very wonderful about our industry - we don't stand (too much) on formal credentials. People don't care all that much about how you learned nonlinear optimization or data structures and algorithms. As a result, the barrier to entry is… well, not low, because any entrance exam that requires proving things about convex sets and doing elaborate algorithms at a whiteboard is not a low barrier to entry, but low in the sense that institutions like law schools can't force everyone to go through three years at $45k+ tuition as a legally enforced barrier to entry (like, you'll be put in prison if you try to practice without the three year, $120K+ tuition degree that many people believe is excessive).

The downside is that because software developers don't have a formal system for demonstrating competence in a way that is widely respected by our peers, we essentially have to take our entrance exams over, and over, and over. Actuaries (last I checked, the exams may have changed) have to take a test showing competence in differential equations, vector calculus, and linear algebra, but I don't think that actuaries with 15 years experience are suddenly asked to find the igon values (sorry, couldn't resist) of a matrix or saddle points in a nonlinear optimization problem with non-linear constraints on the spot during an interview. Physicians have to pass boards and exams, yes, but I don't think they're asked questions from their undergraduate organic chemistry midterm every time they interview for a job.

Slowly, I am starting to think that it would help if software developers could, as a profession, take greater control over how competence is established. I've heard others here on HN say that while they aren't in favor of legally required licensing, they would be happy to study and sit a very formal exam if it meant they could finally be done with the whiteboard interview exams, at least for a period of time. I say this while acknowledging real fear of regulatory capture, but what we have now is really, really bad.

> The downside is that because software developers don't have a formal system for demonstrating competence in a way that is widely respected by our peers, we essentially have to take our entrance exams over, and over, and over.

I don't think it's really possible to have a meaningful and useful standardized formal exam. The issue is that programming, as a profession, is so wide and diverse that it's really hard to formalize what you're good at.

Furthermore, even if you're quite specialized, a large part of your day-to-day work will still be "general" skills, e.g. debugging stuff, fixing other's bugs, taking care of backwards compatibility and working around system bugs. This requires a general level of knowledge of OSes, languages, implementations, databases, networking, ... At least in my experience, but I assume it's similar even in more specialized areas, like security.

Yeah, it may not be possible. Keep in mind, though, that there are plenty of things about being an actuary that aren't tested in the actuarial exams. That doesn't stop them from requiring that actuaries pass an exam involving calculus, linear algebra, and so forth. And as a result, actuaries don't have to go around re-studying integration by parts every time they want to change jobs.

I've been on a few interviews at different silicon valley companies, including Google and Amazon, as well as smaller ones, and the technical screening is remarkably similar. I've noticed it is far more rigorous at some companies than others, but they all more or less test dynamic programming, recursion, trees, lists, hash tables, sorting, and permuting. Even if we all agree that there is no way to have an exam that captures the wide, diverse nature of programming, it could still be useful to have an exam that covers that part that we test over and over and over.

There's one other wrinkle that may not work here - many companies say they do this because they want to see how you tackle a difficult programming problem, how you communicate your solution, and so forth. As a result, they might not be satisfied with an exceptional performance on a similar exam, even if they have high confidence in the board that created the questions and conducted the exam.

Now, all that said, I do consider this to be a really serious problem. Why? Because people who can study for and pass a difficult whiteboard exam on algorithms and combinatorics can pass the actuarial exams, the bar, the medical boards, and so forth. I think that the software industry loses a lot of talent because people don't like the idea of signing up for an industry where they will have to pass their entrance exams over and over, every time they change jobs, and the people who are capable of this have other options. I think this is costing us a lot of talent, it may cause people to favor other fields, and it may cause people to give up and drop out. There are some risks to a formalized test (cartel building is a serious risk, I recognize this, and it worries me - as a math major rather than a CS major, I might be one of the first excluded).

At this point, I don't want to seem like an advocate for this. I'd say I feel ambivalent about it, but that's a change from where I stood on the issue a few years ago. I'm starting to believe that the damage inflicted by what some people believe is "interview hazing" may go very deep. Here's a hint at the extent of the problem...

http://www.fastcompany.com/3043082/most-creative-people/why-...

"Hall asked a simple question: Why didn't Chipps, a brilliant engineer, ever apply to work at Fog Creek? Chipps said she didn't think she would make it through their rigorous testing process."

One last thing - people certainly can agree that there is a problem without agreeing on a solution, especially one that involves a standardized exam.

> I think this is costing us a lot of talent, it may cause people to favor other fields, and it may cause people to give up and drop out.

Personally, I think it's a good thing. It filters out people who are in it for the money and ensures that people who stay despite the shitty interview process are real enthusiasts.

But then again, I'm a programmer, not a manager running a company, so I understand that our incentives are not exactly aligned.

Other than that, I kind-of agree. One of the best interviews I had began with a "standardized" (for the company) test that set the bar with the basics (linux command line, memory management, threads, ...), and the continued with more specific competencies.

> she didn't think she would make it through their rigorous testing process

I though so as well once. It turned out to be one of the hardest, and therefore most interesting interview processes. I'm very happy at that job now.

I see this in HW too to a lesser extent.

I think a lot of this comes from insecurity by the interviewer and the interviewer's need to feel smarter than the interviewee.

Unfortunately, I've interviewed people with 20 years of experience who were only marginally more skilled than someone with two or three years. The "1 year of experience ten times" effect is unfortunately a real one.

For those of you who are early in your career, be sure to keep trying new things out every so often. It's really easy to get trapped because it sneaks up on you; you shouldn't be trying something new every week, because you need some depth, but if you've gone a year with nothing new tried, you may be in some trouble.

And be sure your "something new" is a new type of thing, not just a new thing. Learning Python, then PHP, then Ruby, then Perl, is really just learning one thing, maybe 1.5 things. You ought to be learning a dynamic language, then a static one, then maybe SQL, then learning about reliable cloud programming, then perhaps a full functional language, then perhaps go write a GUI with a conventional GUI toolkit, then learn some dynamic front-end Web programming, write a compiler, write a network app starting from sockets, use SSL for something serious, etc. etc. IMHO, the truth is that the programming world doesn't move that fast, but part of the illusion that it does is that it is quite a big bigger than meets the eye at first. It looks like it is moving quickly because there are things that look new to you all the darned time. But under the hood, progress is actually pretty slow.

It's good to know that I've been doing the right thing, then. I have a hard time being confident though, and pitching the value of that breadth. Most sites like Hired or whatnot ask things like, "how much experience do you have with X", and it always leaves me worrying that at some point in a hiring process there's a rejection filter in place that will only see the shallowness of a particular skill.

Do you have any advice for how I can deal with that better?

On your side, you do need depth in something. This is sometimes called a "T-shape" of skills... broad shallow sampling, and depth in some smaller set of skills.

You should also be aware that hiring requirements are more the wish list of the hiring organization than hard requirements; that is to say, don't "feel bad" about not quite meeting the requirements. If you're close, go ahead and apply. Come in and shine in the interview and only hiring organizations with poor business skills will ignore that you've only got 2 years instead of 3 in Python. (Such exist, though, sadly.)

However, I don't know myself how to deal with people who get too particular. When I'm writing my requirements, generally all my requirements come out as "Blah years of experience in $TECH_WE_USE or similar", and even then I'm really only saying "years of experience" because it's the standard; what I really mean is "a level of skill commensurate with what you'd usually expect after Blah years", but I can only deviate from the standard so far, you know? I don't know what to do about interviewers/organizations who think that 5 years in Perl translates out to 0 years of experience in Python. (All you can really do is comfort yourself in knowing that they're really hurting themselves with such specificity, though.)

> Unfortunately, I've interviewed people with 20 years of experience who were only marginally more skilled than someone with two or three years. The "1 year of experience ten times" effect is unfortunately a real one.

If you are not capable of identifying these people without spending hours of staff time and engaging in whiteboarding exercises, something is very wrong in my opinion. The person you're describing will not be able to pass a thoughtful 15 minute phone screen, and that's if a phone screen even happens because this type of candidate probably doesn't make it past a resume review if the person reviewing the resume is qualified.

How exactly do you think a resume review will reveal how in depth they went on projects and coding? Or even a 15 minute phone screen that has no coding involved? It's pretty easy to list interesting sounding projects you worked on and not mention that you had only minor involvement in them. I'd love to know what questions will actually reveal this.

A good resume from an experienced candidate will describe the work the candidate actually performed. A resume that is ambiguous as to the candidate's contributions is usually worth tossing.

In the case of a phone screen, I honestly find it hard to believe that folks have so much difficulty believing that it's possible to get a good sense of a candidate's skill and knowledge without sitting over his or her shoulder and watching him or her code. A phone screen is a conversation. In most cases, a candidate who is faking it will have a very hard time describing in technical detail his or her work, and answering technical questions about his or her work.

Start with candidates who have good resumes. Ideally get code samples and/or a portfolio. Prepare for your phone screen so you can ask good questions. It really is that simple.

A resume can say anything. Some of it may even be true. So how are you telling the difference between a good resume and a faked good resume? It's just like spam filtering, both the candidates and companies are in an arms race to try to improve/bypass hiring filters.

This level of paranoia is kind of amusing.

If you take the time to review a resume thoroughly and ask thoughtful technical questions about a candidate's past work in the phone screen, the phone screen is almost always going to be a painful and embarrassing experience for a lying candidate. And such a candidate will virtually never make it past a reference check.

The problem is that most companies are lazy. Hiring managers don't read resumes closely and wing it (i.e. jump on phone screens without preparing). Reference checks? What are those?

It's hilarious that you think this is paranoia. I almost wish I could live in your rose-tinted world, where no one lied ever, references were a good way to judge coding ability, and apparently all new grads magically have relevant references.

People can memorize the key features of OOP, but still not be able to use it. So do you not hire new grads? Do you never hire someone with an extensive background in C, because you dare not quiz anyone and you don't want to risk hiring someone who can't really ever get a handle on OOP? Are you going to pay the total cost of all these people, who probably won't last 3 months?

What's even sillier is that I bet most people, given the option, would prefer to try solving some small problems for a short period of time if they knew it could help their chances of getting the job. Why wouldn't you if you knew you were competent?

You'd be amazed how many of these guys make it past even very good resume screens. A resume is easy to lie about.

You're right, phone screens usually get them, but not always. A fair number can still make it through.

I'm curious what you're asking in phone screens that identifies these types. I typically don't handle phone screens, but it's pretty common for us to get candidates with 5 - 20+ years of experience that clearly have not reached a depth of knowledge and wisdom that is commensurate with their years on the job.

> Am I the only one who finds it crazy that at age 50+, ostensibly after working in the industry for at least a couple of decades, a candidate would be subjected to inane technical interviews and useless whiteboarding exercises?

No one should be subjected to useless whiteboarding exercise, regardless of age and experience; conversely, to the extent that skills relevant to the job can be usefully assessed via whiteboarding, there is no reason age or experience (either of which may have provided time to produce job-useful skills, but is not valuable on its own) should get you out of them.

So, while I'm always unhappy with irrelevant exercises in hiring, I don't see the age/experience issue you raise as being relevant to that unhappiness.

Asking a developer with a decade-plus of demonstrable experience to whiteboard is like asking an F1 mechanic to draw an engine and label the parts.

How do you get them to demonstrate successful problem solving and coding and design abilities without seeing them code, then? You're right that it's kind of a silly test, but the problem is that it's a key part of their job and there's no other way to check for these skills, that I know of. And there's also plenty of people who have the experience on the resume and just can't design or code much. It's hardly like the whiteboarding is done for no reason - there are plenty of people it weeds out.

A much better analogy would be asking an F1 mechanic to look at a car you had up on a lift. Sure, they don't fix Hondas all day log, but if they can't see obvious problems and don't know how to solve those obvious problems, it would be a serious red flag.

Even in your silly example, you'd be smart to question it if the mechanic couldn't label a lot of parts they should be able to label, and it would itself only be a small part of the interview.

A good way to confirm that they know their stuff is to talk to their references. What tasks did they do there? What problems were solved using what tools and techniques used? Nobody knows their skills better than those who already worked with them. If their reference seems to be an idiot, that's informative too.

Ask them to bring in an interesting example of their own code to the interview. Let them explain their design and implementation choices. Ask about the problem they needed to solve, the range of input data, the form of output, the acceptable ways it could/should fail. Propose changes to each of these and how they would respond. Propose variations to their algorithms or data structures or fault tolerance or input data to explore their range. Ideally, make the variations appropriate to your business' practices and needs.

> A good way to confirm that they know their stuff is to talk to their references. What tasks did they do there? What problems were solved using what tools and techniques used? Nobody knows their skills better than those who already worked with them. If their reference seems to be an idiot, that's informative too.

Really? You could easily fake that, have a friend who still works somewhere say anything.

> Ask them to bring in an interesting example of their own code to the interview.

That's great if you're willing to weed out people who only code at work.

> Let them explain their design and implementation choices. Ask about the problem they needed to solve, the range of input data, the form of output, the acceptable ways it could/should fail. Propose changes to each of these and how they would respond. Propose variations to their algorithms or data structures or fault tolerance or input data to explore their range. Ideally, make the variations appropriate to your business' practices and needs.

That's what you can do without their own code, but it fails to prove they really wrote it.

No one asks an electrical engineer to design a circuit in an interview, or to identify a bunch of parts. All my interviews have involved talking about projects I've worked on, and about type of work the company does - no test type questions at all.

Why are electrical engineers able to evaluate each other through conversation when software engineers apparently are not?

Earlier in my career, I have been asked to design circuits in interviews. Phone screens have also included in depth discussions of component tradeoffs for various circuits. My most recent interview, after 20+ years of experience, wasn't very technical at all, mostly focusing on team fit and personalities. The whole discussion here of software engineers with 20+ years of experience having to code up fairly simple things on a white board is very strange to me, and fairly far outside my experience.

> The whole discussion here of software engineers with 20+ years of experience having to code up fairly simple things on a white board is very strange to me, and fairly far outside my experience.

Once you start interviewing people with a lot of experience and see how poorly some do with FizzBuzz or 'merge 2 sorted arrays', it becomes immediately obvious why this is done. If 20 years experience was a good indicator, it would be used instead. For positions where there's no coding, this wouldn't be asked. All at least in my experience.

Maybe its a mismatch between practice and experience. When asked how to map phone numbers into words in a dictionary (or whatever), I don't start coding. I draw pictures and data maps and constraints. Maybe I write a critical condition algebraically. After fleshing out all the corners and dark places, then I may choose a programming language and code approach.

So coding exams are almost a litmus test for "inexperienced programmer" in my view. Because an experienced developer doesn't start by coding at all.

You could certainly do all of those things during a coding test, as much as was appropriate for such small problems. I'm sure that would impress people if you did it competently.

> So coding exams are almost a litmus test for "inexperienced programmer" in my view.

You certainly could call them that when they weed out people with 20 years of experience who can't merge 2 sorted lists.

What you've said is true, that it is remarkable how many applicants who look great on paper actually can't code simple things, but these technical interviews go way beyond those simple questions. I've personally failed to pass the technical interview stage at more than one company, and I wouldn't have had any trouble at all coding fizzbuzz or merging two sorted arrays.

Granted, this was at a company with a notoriously difficult technical screen, but it goes far beyond fizzbuzz or merging two sorted arrays. If you can't do that, there's no way you'll pass, but I'd say you need to be prepared to solve difficult questions from "cracking the coding interview" at the whiteboard in 45 minutes or less, without needing a great deal of help. Minor syntax errors are fine, but your code needs to be pretty tight and close to working.

I walk around with the ability to do fizzbuzz or merge two sorted arrays in my head, and I could code up merge sort or find the path from a root node to descendant in a binary tree with a little thought. But really, no joke, in my experience, these interviews take far, far more than that. I can't speak for everyone, but I personally need to study, hard, for a few weeks to a few months to get into this kind of form, depending on how long it's been since I last did it.

I have no doubt that the degree of technical grilling varies considerably between companies, which is why I'm not doubting what you've said here. However, I am certain that it doesn't tell the whole story - and that many of the companies that claim that there is a desperate shortage of software engineers have set the "no hire" standard to the point where they are rejecting people who could easily do what you've described, and much more.

I though that, too. But then I heard from a co-worker that some companies do ask grads to take technical quizes/tests.

Because 95% of electrical engineers have degrees that mean something.

Being a mid-40's dev, here's my view... It's as much a test to see if you'd like to work for that company as it is a fizzbuzz.

You know going in what the process is, are you willing to prepare for it? Are you willing to expend the effort to open the text books, read papers, and arrange your day job to get the practice in?

I've found that the interview prep I had to do was a good indicator of what the job was going to be. So, if you're not willing to do the prep, then perhaps the job isn't for you.

Sitting on the other side of the table, the number of people who aren't able to accomplish a fizzbuzz type question is high. I also get more than just "can they code?" out of it.

I check:

1) for sound engineering practices (test data!)

2) ability to communicate their process.

3) willingness to ask questions when they don't understand.

4) ability to take feedback.

5) ability to work under time pressure.

The technical part is only the first bit. It's a bit hurdle, but it isn't the only one.

How much accurate data on a person can you reasonably get by putting them "under the gun" on a whiteboard? How are you filtering out those whose knowledge ends at the prep work they simply memorized beforehand? I find it more worthwhile to have real, in-depth conversations about code, software, infrastructure, etc. and walk through a few prior projects/code they can bring in and have to show. I find this far more insightful than barraging them with trivial coding exercises like fizzbuzz.

You can't, any more than you can get accurate data about a person by talking to them. They both select for different groups.

I understand that the research shows that the only truly accurate measure is working with someone for a week or two.

Whiteboarding is pretty terrible for interviewing developers, the only time they whiteboard is when interviewing.

It's always amazed me that they don't just give you a laptop to code on.

That's what I do. If the candidate is in the room I hand them my keyboard. If they are on a google hangout I send them a link to collabedit.com. People seem to do a lot better with a keyboard and syntax highlighting.

This is what we do. For frontend positions, we give a laptop and a jsfiddle page to code up the answer to a technical problem that should take about 45 minutes. Then we leave the room and come back in 45 minutes and discuss how they did.

I know I tend to freeze up when writing whiteboard code in front of a interviewer, so I do not want to subject somebody to that when I am interviewing. When you are looking over someone's shoulder, you are not getting a true picture of their ability.

The other thing is that writing code on a whiteboard has nothing to do with coding in the real world. You write some code, test by running in a browser, command line or IDE, refactor, test again etc. Expecting someone to write perfect code without running said code is ridiculous.

Whiteboards should be used for sketching out ideas, i.e. architecting different ways to solve a high level problem, like how should I organize these objects in the application? What should the interface look like?

For large companies there are legal problems there. If you can't give every single candidate the same exact experience / ability to succeed in an interview, you are open to lawsuits. If candidate A got a laptop, but candidate B didn't have the option, B can sue. So if you can't guarantee you will have a laptop at 100% of interviews for a given position, you can't offer it at all.

That said I feel like interviewing is important enough that a large company with (presumably) large resources ought to be able to make sure a laptop is always there. But it isn't as simple as "just bring a laptop", you'd have to have an enforced process.

Not only do we do this, we invite them to bring their own if they wish

When I'm onsite at our HQ, I whiteboard all the time.

I'd guess you haven't interviewed that many people then. IME, lots of people look like they'd be good fit for a higher position like architect, but then when asked to code up a somewhat simple problem they perform far worse than average.

Insanity would be you assuming they are good at problem solving and coding without even checking.

Let's say I'm trying to find the top 10% of software engineers and I'm willing to pay for it. I'm interviewing a 55 year old candidate. What kinds of questions should I ask and how should I evaluate if they are really that good? (Let's say I'm hiring at Slack, to make it more concrete).

I agree with your sentiment but struggle with the question above.

1. Walk through in real detail the candidate's past work. This requires preparation on your part, as you will need to review the candidate's past work, any code samples, etc. If you do your homework and manage the conversation well, it will be very difficult for someone faking it to get through.

2. Present one or two real-world challenges related to the work the candidate would be doing for you and talk about how he or she would solve them. If the candidate wants to draw or write code on a piece of paper or white board, fine. But this should be a conversation, not a test.

3. Although they aren't always viable, contract-to-hire relationships are your friend.

Ask an older candidate, in their experience, which tech or management practices work and which don't. Ask them why they think so.

You can learn a lot about the depth of someone's understanding of the full engineering process: reqs & specs, design, implementation, test, maintenance. Among the places the candidate has worked, ask them about the strengths or weaknesses of various approaches and techniques. Ask for war stories that were learning experiences. Ask for their thoughts on which of these might be relevant within your company (or given a certain set of synthetic but plausible relevant constraints).

In practice, a really large fraction of software dev practices, especially in the early phases like requirements and design, have long been suboptimal. (I'm being kind, of course.) But few bemoan this because, formally, few agree about how to correct it, largely because business problems vary widely. However if someone smart works in business long enough, and they pay attention to more than just their own code, they usually learn a lot about which approaches serve their business well and which don't. That wisdom is the greatest strength of an experienced developer/engineer.

Explore that in the interview, and not just how they would code a red-black tree template in C++ on a whiteboard.

Here are some things I've done recently that seemed useful:

1) Rather than ask them to code something, give them some code and have them review it. I opened up a browser and went to code review.stackexchange.com and picked one in the interviewee's favorite language.

2) Have them show you code they've written. It doesn't have to be from their current job, which would probably violate their employment agreement, but they've probably written some side projects for fun, or worked on some open source, or something.

3) Discuss problems they've actually solved and how they approached it. What did they try that didn't work? Why did they choose the solution they did? Did they consider anything but not try it? If so why didn't they try it?

That way you're not testing their ability to write unrealistic code (who writes their own linked list?) under ridiculous time pressure (less than 1 hour); you're not bringing on test-trauma that wouldn't affect them in their real job, etc.

I find it insane that anybody has to do those whiteboarding exercises except maybe fresh grads.

But, Google does it so it must be the best way to interview candidates. God forbid you should actually get a candidate to write some code for you with a computer or something.

Whiteboarding stuff from your CS exams is hidden ageism. A 22-year-old can rattle off red-black trees becaue they just revised them for the test. An experienced dev can't because when would you ever actually implement it yourself?

It would be crazy if the candidate had been working for you for 30+ years, but different companies have different standards and different people gain experience at different rates and/or stop learning.

For example, I interviewed one guy to become the Tech Lead for a client's SaaS initiatives. He had a lot of experience, but it was all experience with mainframes. And it showed in how he approached technical/architectural scenarios. Especially for senior/tech leads, you don't want to have to retrain them.

How in the world did somebody with decades of mainframe experience wind up in an interview for a SaaS tech lead? On the surface, it sounds like there was a fairly obvious misalignment between the candidate's experience and the experience required by the role.

Somebody like this almost certainly should have been filtered out at the resume review stage or in a phone screen. There is no reason a company should be investing staff time in an in-person interview before it has a clear understanding about a candidate's experience.

One part of the problem is that young programmers are given a sort of computing education without a historic context. The only historic perspective they get on anything is in their humanities courses, where it isn't about their profession.

In their core subjects they are given a cartoonish summary their history of their profession, with distorted dates, which leads them to believe garbage like that object oriented programming was invented in the 1990's, functional is totally new and so forth.

"Like, wow, you're in your 50's and you know about new stuff like inheritance over composition and singletons?"

Only those know better who actually dig into the literature and look at the actual dates, and are surprised how far back some concepts were not only known academically but deployed in production systems.

There is this axiom that, no matter what year it is, someone with gray hair knows mainly Fortran, and writes it in any other language. Be it 1985, 1995, 2005, 2015, doesn't matter. Never mind that the 1985 person of whom that was actually true already died, and this is his son, if not grandson.

can you watch out with the sweeping generalizations?

When I studied, we had a class where we literally wrote our programs in FORTRAN/C, on punch-cards, and submitted them to one of several mainframes that my university maintained. (this was 2-3 years ago).

I get that there's discrimination, but it seems like it goes both ways.

> We had a class where we literally wrote our programs in FORTRAN/C, on punch-cards

C on punched cards going into a mainframe? That class was clearly messing with your heads, I'm afraid.

C was offered as an alternate to people who hadn't learned FORTRAN. Say what you will, I've worked with several people who told me that was a fairly accurate depiction of the way things worked.

But it's certainly not the same as "OOP was invented in the 90's".

I've twice worked on apps that were in modern (for the time) languages... One was VB6, the other was ASP/VBScript that were written like COBOL. The former was rather impressive as it used a few language features I wasn't really aware existed at that time. This was in the mid-late 90's.

That said, if what you write is relatively easy to reason about, well structured and maintainable, I'm much more pragmatic about it now... These days my biggest pet peeve is introducing design patterns where they really aren't needed, and a simpler solution would be easier to use.

I'm 40, and haven't really experienced ageism, though I'm fat, and have experienced a lot of bias based on that. I also work in a town that's more line of business software (Phoenix), so there's usually people older than me... at this point, I'm on the older side of the groups though.

This is a sample of one anecdote that the HN readers who clicked on this story found appealing.

That says something about this site and its readership but very near nothing about systematic age discrimination in the industry.

Sometimes, you just run into jerks. Consider yourself lucky you didn't get the job; if an employee is allowed to be a jerk to candidates, that's a pretty good indicator that their management sucks. An interview is also an opportunity to represent your firm to a complete stranger, and even if you don't hire someone you want to be in a position where they might refer a friend, or provide positive feedback out on the 'net, or whatever.

You can look at this from a slightly different angle:

"...It is often said that “Youth is wasted on the young”. Based on my little spare time study, in this context, it seems truer than ever.

The youth have all the energy and time to spend, no obligations and no financial worries. But they have very little life experience and exposure to these hidden problems. So what they end up solving are the kind of problems primarily young people have. This certainly makes for some very amazing products, but I can’t help feeling a little disillusioned. The amount of time and energy that goes into fun, but ultimately useless ideas, rather than fixing some of these hidden problems is mind-numbing.

On the other hand, the older generations are exposed (aware or unaware) to a lot of these hidden problems. They have experience on how to solve them because they understand them. Yet by that time, most of them have to provide for a family, pay of their mortgage, tuition fees, healthcare, yearly vacations and the 3 cars. They also often lack the imagination on how to solve things in a new technological paradigm.

So I now realized that there is a potential goldmine of problems we simply don’t know of, because the people who are exposed to them aren’t connected with the people who have the opportunity and creativity and energy to solve them. Which begs the question:

Are the old and young generations wildly underutilizing each other as resources? ..."

http://000fff.org/the-problem-with-problems

That's... a pretty insightful observation.

I suppose if you'd create a company that tried to exploit the comparative advantages of young and old staff, you'd face problems of leadership - who should run the show? The young, or the old?

But I think it could be worth trying out in Hackerspace context. I'm adding to my TODO list to try and encourage some 50+ people to hang out in our space; maybe they could contribute some important problems and good insights that the regular young crowd could tackle with the energy we have.

Thank you for sharing that quote.

Thanks.

And yes there is all sorts of issues that could arise for sure.

I have been thinking about ways to force out these hidden problems from people with more experience. Perhaps just doing a bunch of interviews and writing a book/blog about them. Another idea I have is to try make a podcast where we invite people in with experience from industries and then try and figure out what problems hide inside the organizations that we are not aware of.

It all came from an ASK HN i did a while back where I asked "What problem in your industry is a potential startup" https://news.ycombinator.com/item?id=9799007

The answers there were mind-numbing to me cause it showed me how much insight is actually needed not just to solve a problem but also to find it to begin with.

> It all came from an ASK HN i did a while back where I asked "What problem in your industry is a potential startup"

Oh, that was your thread. Then thanks again, for posting that. I remember it because I found it somehow only few days ago, and bookmarked after reading through. The anwser there were not what I expected, and they revealed a whole world of problems that are not obvious but very important and in need of solving. They reminded me of this old edw519's classic:

https://news.ycombinator.com/item?id=1724198

(Also check out http://static.v25media.com/edw519_mod.html if you haven't seen it before; edw519 has posted some incredibly insightful stuff over the years; one of the best programming reads I've ever seen.)

Yes it was quite amazing to get all that great feedback. I tried it on both Reddit and Quora but it didn't go so well could be timing could be that it's lacking the incredible varied backgrounds that HN after all have.

And yes Ed519 always have some incredible insightful comments on of my favorite commenters.

I agreed with this up until this sentence.

> They also often lack the imagination on how to solve things in a new technological paradigm.

I think that they absolutely have the imagination, as well as the skill and experience, to solve these problems. What they lack is tolerance for risk.

Yeah I could have worded that better.

The point I was just trying to make is that older generation might be caught up in certain ways of solving things, where as younger generations might come into it with a different paradigm in mind.

I was trying to make a very specific point but I did that I guess poorly.

The young will often times "reinvent the wheel" not knowing that not only does the concept of a wheel exist, but many wheels before them have been manufactured.

I know I have done this and as I have gotten to middle age I have seen younger developers do this as well.

Wheel reinvention is often futile but sometimes leads to brilliant new inventions. Also, their is an old adage about young scientists sometimes making major discoveries because they don't yet know what is impossible.

> exposure to these hidden problems

I think this is a key to experience. I spent a large part of my 20s diving into problems and totally screwing up the solution. I learned a ton from this.

On the flip side, maybe 50% of those problems don't exist anymore, because new technology or methodologies have solved them. Knowing how to use CVS or SVN doesn't really count for much in a world dominated by git.

I think that's where I value a deep understanding of CS and core engineering practices, regardless of age. Understanding pointers, how to debug, and the difference of the heap vs. the stack hasn't changed much over the years.

Yeah the hidden problems I am talking about are less specific.

Some of them are problems like workers unions standing in the way of automation of some shipping procedure or that people never thought about it as a problem but rather the cost of doing business.

Technology definitely removes a lot of those barriers over time as you say. But there are still plenty of problems that aren't technological and perhaps those are the most interesting.

> But there are still plenty of problems that aren't technological and perhaps those are the most interesting.

100% agree. A lot of problems involve navigating a particular business domain or learning how to work with people.

> Knowing how to use CVS or SVN doesn't really count for much in a world dominated by git.

I don't understand the point you are tying to make. What has git so fundamentally changed that SVN/CVS don't count as knowledge / experience?

Additionally, who says git is dominating? Here, on this forum, it has popularity. In industry its almost unknown. And guess which is the larger part of the world?

> In industry its almost unknown.

Maybe I'm in a microcosm, but everybody in industry I work with switched to git years ago. And I'm definitely not in the valley. :-)

There's danger of selection bias. Would you work for a company that used a different tool?

> Would you work for a company that used a different tool?

Of course.

Most companies I've seen when freelancing as a web dev in Germany either used git or were in the process of migrating from SVN to git.

That said, there's selection bias involved.

A few data points to consider:

1) I happen to work in a dev tools company and we definitely see momentum towards git in our customer base. Broadly speaking 2/3rds of our customers (SMEs, F50s, etc. across a broad array of industries) are using it wholly or migrating to it.

2) Several of the larger proprietary SCMs are debuting git compatibility (e.g. p4), implying a belief that expending engineering resources along those lines is perceived as worthwhile.

3) The stackoverflow dev survey that came out recently had git with ~69% of the market: http://stackoverflow.com/research/developer-survey-2015#tech...

4) GitHub (just part of the git market) has over 10M repos now: https://github.com/blog/1724-10-million-repositories

You can always hope for more data, up to the limit of every programmer on earth answering your question(s), but the trend in the available data is clear: git is extremely popular and becoming ever moreso.

Every company I have worked for, since 2001, has used Perforce. My latest employer was starting to think about maybe possibly using something else, but I doubt it will happen.

I suspect this is a generational thing. The companies I have worked for were generally formed in the nineties or 00s, when the free source control systems didn't exist or weren't yet popular. The companies being formed now use Git almost universally.

I've been writing since the late 80's professionally and had to look up Perforce. Mostly we used stuff we created until the late 90s and then it was Subversion. Once dragged to git about 10 years ago I would never look back. We do host it ourselves for security using atlassian stash though. Love it.

Because Perforce is fantastic. Nothing else comes close. The chance to work at a Perforce shop again might even lure me away...

Those stupid old guys eating steak, when all the cool kids are eating burgers...

In industry its almost unknown.

So unknown that even Microsoft offers git functionality in Visual Studio now: https://msdn.microsoft.com/en-us/Library/vs/alm/Code/git/ove....

Maybe it's not dominating (or maybe it is, don't care), but to say that git is almost unknown is a bit strong, IMO.

> What has git so fundamentally changed that SVN/CVS don't count as knowledge / experience?

I think git (and other distributed source control systems) changed the culture around branching and forking. So, if you're coming from a CVS world, there is a lot of technology that changed, and the technology changed the culture/methodology.

I.e., if you dropped a CVS user from 1996 into today's world, they would have culture shock, not just a new technology to learn.

All source control tools have a different model of the source history. You have to relearn that to change tools.

The culture change mentioned is nothing to do with Git. It has to do with GitHub. We can talk about that too if we want to.

Of course, git was developed by an old guy that used CVS, so....

Replace CVS with BitKeeper, and you'd be right.

Linus never used CVS because he couldn't stand it. The kernel had no version control until BitKeeper came along specifically because Linus wasn't sold on version control until he discovered BitKeeper, and then when McVoy killed their licenses, Linus chose to write his own system because he didn't like any of the existing ones.

I must be getting old

But BitKeeper was created by an old guy (Larry Larry McVoy[1]) who was born in 1962. Not only that, but BitKeeper is built on top of SCCS[2] which predates RCS (and RCS predates CVS).

BitKeeper was a totally new solution to a very old problem that was "solved" years ago. It was created by an "old guy" who knew the wheel had a large flat spot and figured out how to make it round. It was subsequently adopted by another "old guy" (Linus) who refused to use wheels with flat spots.

[1] https://en.wikipedia.org/wiki/Larry_McVoy

[2] https://en.wikipedia.org/wiki/Source_Code_Control_System

Are we confusing age and culture with stupidity?

A stupid person wouldn't be able to adapt, or might have trouble adapting from one tool to another. That's a stupid person. Likewise a stupid person might think that an organization that was shipping successful products and making money was making a big mistake by not migrating off of svn.

Stupid is stupid, age is a different dimension. "culture" especially regarding tooling like this is sort of a cop-out.

It's true! I did a fair bit of programming and other computery things in undergrad and had a pretty good track record for, say, transforming some trash from behind the CS department into a workable computer. I was happy with Emacs, resisted vi, could whip up a nice html page with some cutting-edge CSS 3. By no means did I have special talents but I was sort of up to date on a broad range of basic computer-related skills, from hardware to networks to web design.

But then... I went to grad school in pure math. Seven years later, I emerged from a rip van winkle sleep to a whole new world. Still hand-writing my html, like all mathematicians do, I was astounded to wake up to a world with... frameworks?! AJAX! Rails! widespread use of IDEs, an IDE for every language or taste, Javascript everywhere... Python and Ruby as non-fringe languages....

It was a bit of culture shock and it was fun.

The major concepts are still the same.

I can agree with this on so many levels. As a student in a somewhat challenged branch of it, I often feel like me and my fellow students are "wasting" time on merely explaining theories, when in reality, a lot of us are very eager to get our hands dirty with something real.

Universities have a limited amount of ressources which means that you're pretty much left alone to figure your entire study-plan out to yourself, including picking partners and/or cases for examns. While this is not at all impossible, I know for a fact that a lot of students around me are eager to participate in something that weighs a little heavier than their own interest in social media or gaming.

Yes thats my experience with a lot of young people too. So the question is whether there is some way to channel the experience of hacknat's father (see his comment) and make it available in a way that make sense to younger generations?

Is it even possible to bridge or are we just left with the cold hard facts that these things only happens when they happens.

To piggy-back of off this. The hidden problems aren't just extensions of old-age experience vs young-age experience (i.e. social-network vs hospice placement). It's often domain expertise vs none. There are so many older folks out there who have had decades of experience in one domain that none of us have even heard of, or are only, maybe, vaguely aware of. They are aware of that domain's problems, know most of the key players, etc.

My father is a Director-level exec at a Fortune 100 company, and I've talked to him, ad nauseam, about the problems he wishes the enterprise line-of-business crapware his company keeps purchasing would actually solve. I keep trying to convince him to strike out and do something, and have even offered to go in on something with him, but he's just too comfortable. He has more than enough money, and he's decided to retire early if he doesn't get the next promotion he's gunning for.

He was recently honored by the trade association of the domain he's an executive in (I guess there's no harm in saying it's logistics). I'm sure the contacts he has would send a startup hurtling into the stratosphere within a few years. How many people are like him out there, who are going to waste all their domain expertise on retirement or the next promotion?

I feel like someone needs to write a manifesto to the older and successful among us about how they owe it to themselves and the younger generation to disrupt the industries they've been leading for so long. These fat-cat, lazy ass, companies just get to skate by on pure inertia.

Exactly! But they don't even need to be successful. Just the fact that they have spent years dabbling with something.

A slightly absurd example of a way to surface this would be to do a kind of "retirement interview".

If he retires early, that's the perfect time to pull him into something entrepreneurial. When the viable alternative is "play golf", a stab in the dark looks a) more interesting and b) low risk (because you can always go play golf).

I think the role of fortune 100 companies is more to keep the lights on then disrupt. Disruption and new direction rely on a foundation of the current state. Yes that foundation will be replace, but only by the best of ten disruption that survived while its peers perished.

I think we all agree on that.

The Parent was just saying that his father complains about these "hidden problems" and the parent wished his father would strike out on his own and solve some of them.

But thats just how I read it.

>These fat-cat, lazy ass, companies just get to skate by on pure inertia.

How long before young and sexy startup becomes lazy fat cat nowadays? Maybe ten years? So, now the older crowd needs to constantly re-do everything because the younger guys got lazy? I'm not sure what the solution you're advocating here is. Eventually, everyone becomes a fat cat it seems, at least to the eyes of the new guy. I suspect the $bad_vendor or $bad_project isn't that bad and the time/work commitment to constantly re-do it is non-trivial. Especially if by the time you finish this big rewrite its already obsolete or unlikeable in some way -- not HTML5 or not whatever is hot right now.

I think part of maturing is knowing how to recognize the grind and when to actually disrupt it in some way. Is $boring_logistics app really the problem that needs to be solved at $big_co? Arguably, the execs have better things to do and that judgement is what we're paying them for. When it becomes a problem they should know and address it, but to a young guy spoiled by ultra-shiny ipad apps, well, that logistics interface looks "old and boring" but its actually doing the job well.

> but he's just too comfortable.

Perhaps this is besides the point, but maybe there's a shelf-life on human 'can do' attitudes? Ten years ago I'd do anything that piqued my interest, obsess over it, and now its a lot more difficult to get excited and motivated especially if you have been in the grind long enough. At a certain point you realize this is all folly. Another product, another roll out, another set of unhappy/happy customers, another sales projection, another competitor to worry about, another thing that will obsolete in a week, etc. From a psychological perspective, we don't often talk about what it means to have a lifetime of work under your belt. How does it affect us? Is it reasonable to spend ages 22-65 working in the same industry/focus?

Imagine if we put monkeys in a cube and forced them to do the same-ish things for decades. We would probably be arrested for animal abuse. But its okay to do to people apparently. Maybe have some sympathy for the codgers, they're as much victims of this weird world we call work as anyone.

This is an interesting question: is there a shelf life on "can do" attitudes? I think just in allowing that this fact might be true changes my perspective -- hinting that we might be in a kind of startup-frenzy groupthink even in this discussion.

As an upper 40ish something who has been coding since I was 10, this one made my day. So very very true.... but it's amazing how many 20 somethings are to narrow in their thinking or too lacking in medium to long term vision on projects and just hack together a bunch of web found code to make a non extendable solution.

Then there are those who I call the 'google' generation, they just google the problem and proclaim the number one result as the solution without really understanding what and especially why the problem really is occurring.

Every generation has it's exceptions, but also each has their share of averages. Great article, nice way to start Monday morning.

I also developed before web framework proliferation and stackoverflow.

I see most of these things as speed boosts. If you take the rose colored glasses off, in the old days - we simply worked slower on easier (though more interesting) problems. We didn't have to deal with so much damn integration and the mountain of spaghetti we've built!

The non extendable solution gets the job done as well. No need to worry about 'technical debt' when the vast majority of your projects never see scale. Moving faster is better.

When I see a developer wasting too much time on the above - not googling the solution, spending too much time overengineering, and not using the libraries available (not hacking together components)... well, I guess I'm disappointed.

In the old days, I did think more in your terms. I changed to fit the needs of the time.

Technical debt is not an issue, just, of scaling code (presumably you mean to large numbers of connections or database sizes or something). It's really an issue of maintenance. The more technical debt you have on a project, the longer any round of maintenance will take. Even simple tools that are just slapped together quickly might be easier to rewrite than modify, but rewriting them each time results in a different sort of technical debt. Implementation X has features used by user A, implantation Y has features used by user B, so now both tools have to be maintained or you try for Implementation Z that tries to pull it all back together (but probably fails, because you're still not properly budgeting time and engineers).

Overengineering is still a problem, but underengineering is the one I run into more often.

Oh i agree with both of these responses. It's not that google is a bad thing, personally i laugh at how we used to have a wall of books to run to. It's more of the 'take the first google hit' that i was referring to. Not understanding how routing in the firewall works, just throwing code that seems like it might be what is occurring.

Yeah, that's definitely a problem. I kind of miss the wall of books, though. Though I came in at the tail end of that era (more while I was still in school than after). I get a better understanding for things when I have a physical resource to go to. It helps that I (apparently) have an above average memory, but it works mostly by associating the physical act with the information I learned (I remember notes by recalling literally writing them on the page, for instance). So books seem to be more effective for conveying information to me in a retainable way, and I imagine that I'm not unique. That many of my colleagues with "terrible" memories are really just suffering from using the wrong resources to learn subjects, something about the computer screen as information source seems to stick less for people.

My pet theory: The lack of other senses involved. A book has smell, texture, and then the physical act of turning pages. A lecturer versus a video, the lecture hall at least has a smell and feel to it, and there's more variation, less polish, on a live lecture compared to a video that's been thoroughly edited.

I know a woman in her mid-60s who has been programming since the late 1960s. She's much more than an "experienced dev": she is a sage, a teacher, and a grand-master of the art of computer programming: a true engineer in the very core of her being. Yet she can't find steady employment. She believes that is because of age discrimination, and I cannot help but to agree with her.

Don't know if this is the case in the US. But generally, mid-60s people are shied away from being hired because they will retire shortly. Investing in an employee that will be gone very soon is a thing few companies would do, and not unique to IT by any measure. The exception being when they have a need for her exact talent.

Which will end first, the employee's career or the startup? Funny that this is a consideration given how short most runways seem to be.

That's a great point I haven't seen anyone else bring up. It's worth bringing up again in any discussion involving startups. Many barely last a few years. Who are they to talk about what an employee will do in the next 10 years lol?

Answer: "If you're good and VC's like you, I'll be working with you on your third startup by then."

How long do younger people stay at a job, on average? I'd imagine it's 5 years or less. In fact, I'd argue that a person closer to retirement might be more likely to stay longer than someone just starting out. The younger person doesn't have kids, a mortgage or roots put down, so it's much easier for them to leave.

On the flipside, neither does a person in their 60's, most likely. Kids probably have all moved out, mortgages are probably paid off. As a person ages, they become more able to shift themselves, barring special circumstances like a sick spouse.

>How long do younger people stay at a job, on average? I'd imagine it's 5 years or less.

Yet if you admit that, it counts as a mark against you while being hired. It is one place where those hiring are outright ignoring reality, and instead prefer that everyone pretends we are making life long arrangements. Anything that breaks the playing pretend game counts against you; be it honestly stating you think there is a better chance than not that you'll have moved on in 5 years or being of enough age that the interviewer thinks you will retire within 5 years.

Looking at industries, I'm starting to feel that at the age of 50+ you can't really expect to pop up out of a blue with a nice CV and get hired. You have to keep in the flow - change projects, jump companies, build a network of people who know your skills and can recommend you when there are people needed for a new endeavour. It's probably not good, but it seems to me it works this way everywhere.

An issue with 50+ is, everybody looks at your resume and says "Why do you want to work at our position?" Because, you've done so much at so many levels they assume you should be a VP or something, and no longer be developing.

Inverted funnel: suppose there are ten programmers to every VP. As the programmers age, what happens to this ratio?

Could you link her GitHub profile?

Github profile is pretty meaningless as an evaluator of professional skill, outside a very small number of fields.

Almost everything I've written professionally in my 15 year career so far is closed source and not going to turn up on Github.

Not mutually exclusive. Why can't you have some hobby stuff on github ? I guess you might have to get permission in some companies, but not impossible anywhere I would think.

Also isn't programming one of those fields.

'pjc50 by "field" probably meant a subfield of software, like "sexy websites built on node.js". Not all types of software jobs yield Githubbable results.

That said, she definitely has something to share - if not open-soruce hobby projects, then at least interesting stories from jobs she did and battles she fought. I'd love to read such account.

I suggest Philip Hazel's technical memoir (http://people.ds.cam.ac.uk/ph10/CIHK.pdf), which goes through his career.

Downloaded and saved to my "to read" folder, thanks!

> Not mutually exclusive. Why can't you have some hobby stuff on github ?

So now a professional programmer also has to program as a hobby too? Doesn't that set the bar a little high? What if your 'hobby' code is also closed source because it's for a side project?

What if your hobbies are thinking hobbies but not programming? What if your 'building stuff' fascination is more multi-faceted than just software?

I get that GitHub is great for employers because it allows them to evaluate a person's chops, provided that they have a substantial enough body of code published. But that only works for people who have some way to publish their work or personal code. Not everyone does that, nor is it practical to expect everyone to do that.

> Doesn't that set the bar a little high?

What kind of argument is it that an employer has the bar 'set too high'? Put yourself in their shoes; obviously you're going to hire a photographer/contractor/programmer who can show off a portfolio over one who just talks about it. It's silly to suggest otherwise.

If only 20% of programmers have a portfolio that they aren't bound by a contract not to reveal, does that mean programmers should be 80% unemployment?

I hear what you're saying of course, the easier a person makes it to have their work evaluated, the easier they will be hired.

But I think it's obvious that there are a great many good programmers who do solid work but don't program as a hobby too, and whose professional work can't be released because it's proprietary.

What I'm suggesting is that the notion advanced a couple of comments up of "everyone can have stuff on GitHub" isn't realistic for a variety of reasons and I tried to touch on what those reasons are.

EDIT: I of course agree that an employer should be able to set whatever standard they want to hire people, too. What I'm suggesting is that it's not really practical for every employer to hire to this standard.

>If only 20% of programmers have a portfolio that they aren't bound by a contract not to reveal, does that mean programmers should be 80% unemployment?

No. There is no should or should not, there is and is not. And the 'is' of the matter is that a candidate with a portfolio will be ranked higher than a comparable candidate without. That is only one factor, and other factors can still override that factor. And sometimes, you may be applying for a job where no programmer with a portfolio has applied.

I see no problem even if every employer wanted to use this standard, as long as the employer realized it was only one factor of many and not some gold standard.

>So now a professional programmer also has to program as a hobby too?

If they want to get hired easily, yes. (NB: I don't have any code up on github)

Hiring sucks, interviewing sucks. Existing code on GitHub - which can be discussed makes it easier. It creates an online reputation that an interviewer can judge you on without asking 20 extra questions. People are people and are going to take the easy way out rather than come up with good ways of interviewing people who don't have their hobby projects online.

"Any inventions, innovations, or ideas, conceived solely by the employee or jointly with others, relating to any current or future business of the company, at any time during the term of employment, are considered property of the company."

That was part of the employment agreement I had to sign when I worked at a large electronics/telecom company a number of years ago. So anything that could have been put on a public facing site (including technical articles) was not allowed. Of course, you could get a waver for individual projects but that had to be granted by I believe a VP level employee. Oh, and if you were to seek out that permission, unless you were already a superstar performer, you'd hear thing like "How do you have time for these side projects when you are behind on xyz project".

> "How do you have time for these side projects when you are behind on xyz project".

Nights and weekends ?

derekp7's comment is spot on: most workplaces have restrictive IP clauses. I've negotiated mine away so as not to impair spare time projects, but it's been years since I've had the inclination for serious recreational programming. Not that I don't have a couple of ideas. I have seriously considered making a 'portfolio' project if I were to start looking for jobs, although I'm now at the kind of company where I could just sit and wait out the quarter century until I retire if I wanted to. But I just regard that as pushing up the cost and effort involved in jobseeking. My most recent round of jobseeking I relied on finding a non-evil recruiter (HN passim), but I did have one company ask for my github.

TeMPOraL is correct that by "field" I meant "websites" or "ASIC design" or "CAD software" or "embedded". Even at my previous employer (small consultancy), only one of 10 of us had a github with anything on it. Currently I'm in an environment with technologies like MFC and Borland Delphi.

I have >8000 HN karma and >17000 electronics.stackexchange karma. Can I trade these internet points for job offers? Possibly the latter.

I do have a bunch of war stories ("linux upgrade escalates into needing to solder a floppy drive", "three ended ethernet cable", "structured exception handling isn't", "how many managers does it take to change an SSL certificate"), but like most people I'm not Richard Feynmann and don't think they'd be entertaining enough. I'll talk about them in interview if relevant.

(I'm hoping the 99 in your username is a disambiguation number like mine and not an age like some people's!)

Please do share those stories. You don't have to be Richard Feynman to write something interesting and entertaining!

What if you don't like to write code as a hobby?

> Why can't you have some hobby stuff on github ?

I see two reasons:

1. Your employment contract forbids it. My previous job had a stipulation that they reserved all rights to any related outside work and until permission was explicitly granted by the CEO who deems it is unrelated, no code written during your employment could be released. It sucked. It was part of the reason I left. But those types of contractual requirements exist

2. You don't write code as a hobby. This is me. My GitHub has a Redmine theme fork that I maintain for our installation and a simple project written in ArnoldC because it's ridiculous. I don't leave work and immediately go work some more. I'm already putting in 45-50 hours a week. When I go home, I want to read, watch TV, go to the movies, play video games, blog, etc., not code. As far as I am aware, this is common on my team. I think only a single person has anything of worth in their GitHub and several employees don't have accounts at all.

The growing trend of seeing "GitHub Account (Required)" on job applications is worrisome. Yes, it can be a good indicator if they use it, but a lot of people don't. A lot of people can't. A lot of people simply do not want to.

I have a bunch of code on GitHub, but I sometimes wonder about taking it down or making it private... A lot of it is old and hacked together (not as much attention to detail for a quick side project), so I wouldn't want to be judged solely on the quality of my GitHub account.

Point being, even if the person has open source code, it's not necessarily an accurate reflection of the work they will do for you.

Very little of my work is on GitHub either (I haven't really touched it since last time I actively applied for a job, years ago).

The general point I wanted to make is that it's much easier to make the age discrimination case if the person in question is doing all the same things that people who get hired do. Maybe all her work is in COBOL and no one wants to hire COBOL programmers. If you are a master and a sage etc. and you can't find a job, and you don't know to throw some stuff on GitHub or otherwise signal that your skills and practices are modern, you might be out of touch.

And there it is. The first inexperienced thing you could say. Assuming all work in your little world is on github.

I was expecting this response. :) I assume none of her work is on GitHub, actually. But there's a difference between not hiring someone because she's old and not hiring her because she's out-of-touch. If she isn't doing the things that people who get hired do then I don't think it's fair to assume she's being discriminated against due to her age alone.

(I work for Google, which I assume is not what you meant by "little world", and haven't touched my GitHub profile for years, FWIW.)

Is she a badass engineer or is she a sage? I don't mean it to be offensive but I've worked with oldtymers that wanted to coach more than actually do. They have tremendous knowledge and experience but if they're advisors or extra managers, they aren't building; some companies need and can afford that and value it, a lot of startup type places see that as an extra cost.

Our industry has these polar ethos that are pretty deep: one group sees old product that has stood the test of time as an indicator of quality. Like "UNIX has been around over 40 years, it clearly did some things right." The other, and it's insanely popular right now, thinks that anything that is too old clearly has some damage and its no longer good technology, like the neovim crowd, "vim doesn't even use the newest C standards features.." Some times you have to believe that you're doing something different and everybody did it wrong before and that's while you'll succeed this time, that's how you take the risk and ignore the downsides. being old can be a detriment to that belief.

To evaluate whether age can be used as a descriminator for those attitudes and behaviors, I suggest you substitute "woman" or "black" and see how that reads.

There are young people who will only use the tools they are comfortable with. Ageism is the mistaken belief that this is somehow associated with your most recent birthday, akin to astrology.

I'm not endorsing or accepting discrimination, I simply offered up a meek rationalization as I see it.

Honestly, if you find and older person that wants to work at a startup, there is a good chance that they could be doing a few things right to have that energy and drive. You want to know how they live and what they do.

Ahistoricity is one of the things I find infuriating about this profession. Because everyone's an autodidact. I don't mind the argument that "everyone did it wrong before" because that's sometimes true, or something underlying is really different, but it needs to come with some actual awareness of what constraints "before" was operating under, and what was and was not achieved.

Is she looking now? What does she want to do? My company has lots of openings.

Does she have any prose or code online?

No one seems to talk about the elephant in the room: salary. Isn't a more experienced person going to cost more? Are you going to feel comfortable offering them a low salary (relative to their experience), because that's all you got to offer?

And the other way around, even if you would love to have an experienced developer, what do you do if for the same salary you can get an average developer (who will get the job done, because you already have experienced enough people to help), and another profile (sales for exemple)?

This is especially true at small companies, where there just isn't that much latitude to adjust the salary.

Perhaps, but it's not like you have to pay 2x or 3x more to hire a programmer in their 50's. More like 20% or 30% more. For 200% to 300% more experience. That's a deal, in my book.

It depends. It's possible to find a younger programmer who is less confident in their skills or vastly underestimates his net worth. This tends to normalize with age and experience, so an older programmer with the same skillset is likely going to be more expensive simply because they know how much they can ask for.

Similar to the effect of women being paid less because they are less likely to ask for raises.

>Isn't a more experienced person going to cost more?

Sure. But everyone's looking for senior developers. And salary tends to top out for senior devs, so it's not like salary scales linearly with age.

> No one seems to talk about the elephant in the room: salary.

This is not true at any company that "hires the best." If it is, they don't "hire the best." They hire the best they can con into accepting a competitive/artificially-low salary.

So how should an older developer who doesn't need a high salary communicate this? All the usual job hunting advise is about making yourself seem more valuable - i.e. expensive.

A lot of companies ask what salary range you're expecting. The standard advice is not to be the first one to give out a number, but here you can specify a lower range.

So you're OK with discriminating against someone due to a factor they have no control over because of what you think some people like them might do (in this case, want more money)?

60+, programming for 44 years, triumphed over adversity more times than I can recall, wimpy looking nerd discounted by almost everyone I ever met. Hardly ever got the girl, got to be on the team, got the part, or got the job.

I'm a programmer because I can code, and at the end of the day, that's all that really matters.

You can hate on another person because they're too old or too ugly or too nerdy or too black or too female or too gay or too anything else, but the real beauty of our field is that success is binary and relatively easy to measure:

  1. Can you build it?
  2. Does what you build matter to someone else?

I've always considered rejection for any reason a self solving problem: if you're too stupid to accept me (whether you're in Silicon Valley or not), then I would have never wanted to work with you anyway. I'll find someone else who understands the value I produce and can provide the environment in which I can thrive.

Life is unfair, especially in Silicon Valley. It's not about the unfairness, it's about our response to the unfairness.

There has never been a better time and a better way to succeed than building software today. It doesn't matter who you are, where you're at, what you're like, what you have, or who you're with. 95% of the battle is what you can do. So go do it.

95% of the battle is what you can do.

If you're in a minority group that suffers discrimination then that discrimination skews the balance away from being 95% what you can do to more like 50% what you can do and 50% what colour/gender/sexuality/age/etc you are. And a big chunk of the 50% that's discrimination is the fact that people outside of your minority grossly underestimate how much of an issue discrimination is.

If you see something that's unfair it's not especially reasonable to just ignore it with a "Life is unfair" line.

I think what he is trying to say that it is possible to publish an app or service online and gain momentum completely by marketing it on the web. In such case, I do not see how your color/gender/sexuality/age/etc would matter. You could hide yourself behind a domain and nobody would ever care who runs or maintains the thing.

It would be nice to have a job with which you can pay rent and buy food, and pay for that web hosting.

Sure. But complaining about "discrimination" (even if that's accurate) is still complaining. Feels a lot better to just grin and pedal up that hill faster than the kids.

I'm 48 y/o.

http://www.eeoc.gov/laws/types/age.cfm

"Age discrimination involves treating someone (an applicant or employee) less favorably because of his or her age."

Technology is an empowering force. Whether you're starting at the top or the bottom, it will help you. If you're going against headwinds, it will help you.

The parent's advice is solid. If you want to get ahead there are few choices better than becoming a great developer. If you want to get ahead in spite of discrimination then it's probably THE best choice.

Its 95% about who you know. You can be the best coder in the world but if you can't get your foot in the right door you will just be coding away in obscurity. Why is it that 90% of startups seem to be the valley?

Heh, I've often mused that the "best coder in the world" really is coding away in obscurity in the middle of some cube farm somewhere (no doubt making somebody else very rich), and we will never know who he/she is.

I'm willing to bet the objectively top ten best coders in the world are people that 99.9% of the world has never heard of and will never know who they are/were.

If you're a great programmer you will get the opportunity to know others in your field. Being a great programmer implies some sort of collaboration.

> Life is unfair, especially in Silicon Valley. It's not about the unfairness, it's about our response to the unfairness.

> There has never been a better time and a better way to succeed than building software today. It doesn't matter who you are, where you're at, what you're like, what you have, or who you're with. 95% of the battle is what you can do. So go do it.

Thank you very much for the golden words. I wanted to complain something here, but your words let me be confident again.

"if you're too stupid to accept me (whether you're in Silicon Valley or not), then I would have never wanted to work with you anyway."

This plus having F.U. money can go a long way towards getting that perfect job. Sometimes you need to be in a position of strength and have the financial resources to hold out for the best offer. There are a lot of crap jobs out there right now as employers can pretty much dictate the terms. Over time, this will change, and you need to be able to hold out until conditions do change.

"I'm a programmer because I can code, and at the end of the day, that's all that really matters."

That is so patently untrue it's not even funny. If that were the case, then we wouldn't even be having conversations about agism, sexism, racism, lack of diversity, etc.

"I've always considered rejection for any reason a self solving problem: if you're too stupid to accept me (whether you're in Silicon Valley or not), then I would have never wanted to work with you anyway. I'll find someone else who understands the value I produce and can provide the environment in which I can thrive."

That's of cold comfort to someone looking for a job, and constantly being rejected because the employers are "too stupid".

"Life is unfair, especially in Silicon Valley"

So? So we should continue with it being unfair? Or should we be trying to make it more fair?

That argument, to me, is the argument of someone who's either benefiting from the status quo, or just wants to make themselves sound better.

"It doesn't matter who you are, where you're at, what you're like, what you have, or who you're with."

Again, this entire thread is about the fact that it is just that.

Funnily enough, working 80 hour weeks for stock isn't really much of a winner if you have a mortgage to pay and or mouths to feed. The ping pong table doesn't make up for it either.

A few comments here saying that salary is the elephant in the room, which is a valid point, but I think the biggest elephant is the insecurity which lurks in the heart of every entrepreneur.

Co-founder/C_O types in their early 20s are often intimidated by people 35 and older, especially when those people have a long record of working in tech and all the war stories to prove it. The thought of hiring such a person, even when they are superbly qualified for the job and amenable to the compensation package, makes young entrepreneurs a bit uncomfortable.

I think there are two specific fears that drive this feeling of discomfort. First is the fear that older employees might see right through the fact that they have no idea what they're doing and call them out on it.

Second is the fear that older people will destroy the culture through their relative lack of enthusiasm and exuberance. In young founders' minds, it's better to hire someone who's been drinking legally for all of 18 months and who can be counted on to nod earnestly when you talk about "our mission" at the all-hands.

Never thought about it this way but there is probably a lot of truth to it.

Older people have had people trying to feed them bullshit for much longer. They know what it tastes like. They can smell it coming.

Of all the software places near me, the ones that are known for 60+ hour weeks exclusively target young, fresh out of school candidates who don't have the experience to know they are being treated like crap.

> First is the fear that older employees might see right through the fact that they have no idea what they're doing and call them out on it.

I think your comment is pretty fair. For this specific point it's helped me greatly over the years to realize that, honestly, no one knows what they're doing. Entirely, anyway. People in the industry have more experience so they can make better decisions (theoretically) but much of the technology used today was created within the past few years which is an awesome equalizer.

Reminds me of when I was told years ago that the army likes to get recruits at 17, because a 17 year old will buy into the indoctrination. An 18 year old will just go through the motions.

In sports (I'll use Hockey as my example here), teams that are going through a rebuilding phase to stock up on young talent will often bring in a few veterans, players who are past their prime physical ability but are deep on wisdom and experience. Their presence there is to stabilize the new players. They (often) provide a calming presence ("Down by 2 and 3 minutes left? Bah, been here plenty of times. Don't panic.") and provide leadership.

However, you won't see them wearing the Captain's "C". That's the job of your young star that the team is coalescing around. Instead, he's there to be the mentor, the teacher, and build the new for their role and help them avoid mistakes. Lemieux mentored Crosby. Sergei Federov mentored and played alongside a rising Alex Ovechkin. The older guys were well established. They'd been young, excelled, failed, and seen it all. They had valuable lessons to impart and weren't as prone to panic or mood-swings.

Startups have some good resources in organizations like YC to get that level of mentor-ship, but perhaps it would be worthwhile during that incubation phase to impart on those new companies not to dismiss your older workforce. Making your new founders understand that they're not to be feared, but consulted as a source of wisdom could steer them around potential mistakes, and provide that steadfastness when the cluster craps itself at 2AM.

Of course you want everyone to believe in your vision, even if there's some skepticism, you need people behind you to succeed. It's perfectly reasonable to evaluate on that.

But if I were in charge of an incubator, I'd be instructing that founder that, when she or he is building that young crack team, grab a few veterans as well. They're in this for the long run.

The Cup awaits.

Very insightful, and very well said. I hadn't thought of it that way, but I think you have probably hit the nail on the head.

I should add though, that I think it works the other way too. You could also have the problem that the 35+ year engineers look down upon the 20 somethings and communicate it, perhaps unknowingly, in subtle, or not so subtle, ways.

It almost feels like an animal hierarchy problem where you have an older male being added to the herd and the young pack leader is worried about this older male challenging him, while the older male thinks he can and should challenge the younger one.

Makes me wonder then, do women face age discrimination?

We live in a society that still, to some degree, teaches us to respect and defer to our elders. That can add complications to a superior/report situation that many do not want to handle or which makes them uncomfortable. But while they will feel uneasy about the hire, they may not realize this is the cause of it, and they could likely chalk it up to a general 'bad gut feeling' or such, not realizing their reasoning is discriminatory.

This is my biggest fear as I enter my 30s in a number of months. I've been programming professionally since I was 20 and for fun since 10 - I can't imagine having to do something else, it's what I was born to do. I'm still relatively young but I just got married and the long hours and complete commitment I used to wear as a badge of honor no longer seems appealing.

Am I going to be able to do this for the rest of my career? I honestly doubt it, but I have no idea what I would do instead. My father was a draftsman for years and made good money but the market for draftsmen completely dropped out and he spent the last fifteen years of his career unlocking doors at a school. I have such a strong desire to stay relevant but I can't spend nearly as much time studying as I used to even a year or two ago. Sigh.

You'll be fine.

I'm a few years ahead of you. I had the same fears. I was newly married and didn't feel like I was ahead of the game. I'm now 33 and have a house and two kids. It's a trip but I'm still a programmer somehow.

Companies come and go. They go on huge hiring sprees and then either go under or layoff people in a few years. Few, if any, will invest in you long-term or care about the stability of your family. So don't count on having a career path the resembles anything like what your parents or grandparents enjoyed.

"Retirement," doesn't seem like something on the menu for people in our generation or the ones to come.

So plan for it yourself. Education is your best, first defense. Study the right things (Maths should be the top of the list IMO). Next plan to save everything you can and spread it out into investments in a good balance of stocks and bonds. If you decide to have kids start an education fund right away and look into any grants or assistance you can get from your local government to kick-start it; if they do better than you in life then chances are your retirement will be fairly comfortable.

You can still stay sharp. You just have to change the yardstick. My young friends always talk about the latest languages or frameworks but it always comes back to data structures and transformations. I've just learned to be more picky about how I spend my time because once we started having kids I've had far less of it to waste.

I think this is solid advice. I continue learning by picking problems/inconveniences I encounter while working during the day, and then doing whatever research is required to make those things less inconvenient. In the process of researching the problem space, I'm often introduced to new programming concepts and tools that I would have otherwise never known about. Overall, I find it easier to learn new things if I have a real problem I'm trying to solve.

You have to learn to just put in your 8 hours and go home. If you're working more than 40 hours you will not be any more productive than if you worked just 40. If anyone give you slack for not staying late I'd tell them to review your code.

SV programmers need to worry about turning 30 these days? I'm 29, two years professional software dev experience (+5 years university), got my Masters degree last year. I really can't fathom a world where employers would consider me too old. (Europe).

I was more looking ahead into my 40s and 50s. I feel pretty comfortable that I'll have work well into my 40s but after that who can say?

While most of us are pointing fingers at the fast-changing nature of and innovation-craziness in the tech industry, I think the core reason may be quite the opposite.

It seems plausible that the tech industry, innovation-wise, is actually in a rut where companies are forced to cut costs and survive by hiring young people whom they have to pay less. The changes happening in the industry today are of a fickle and shallow kind, not fundamental and lasting. And in an evolution-like process the older amongst us, who are the only ones with enough experience to really innovate, are being driven out of the ecosystem and forced to disrupt an industry going stale.

That is an excellent point. Well done. That being said, speaking as someone who regularly complains about old people in just about every capacity, I think good old fashioned prejudice is playing the biggest role.

  > companies are forced to cut costs and survive by hiring young people whom they have to pay less

.. and yet still starts up in Silicon Valley, among the highest salaries and real-estate prices in the world.

Silicon Valley startups are to investment what a day at the races is to a broker. You hope you'll pick a winner but ultimately those horses are not where the majority of the population's investment goes.

What's your point?

The salary for any given employee is not a limiting factor. I think this is true. Even when you have a very limited budget, many places will prefer to be under head count with a higher performing team. If you can get that guy who is going to let you avoid running down rabbit holes all day, every day, they are worth the extra bucks.

I think the problem is that these people are hard to find -- whether young or old.

"I think the problem is that these people are hard to find -- whether young or old."

Find as employees, and its harder to find them as they get old. I've already found myself, my family and I have a high standard of living without having to put up with open offices, long commutes, cult like office culture, more than 80 hours a week, or less than six month runway till we're all unemployed. Maybe I could be convinced to consult? The odds of this being the situation at 42 are a bit higher than at 22 and the odds rise over time.

Life is different now, WRT culture fit, for example, a quarter century ago employers didn't care about my religion or lack thereof, or my reading matter or hobbies, but now its all about everyone trying to fake that they're the same 22 year old kid, which is really weird. I think I'm a pretty good actor and if I got accepted into a cult like environment, it would be really weird for everyone when I stopped acting, so I'm not sure hiring people based on acting skills is necessarily producing culture fit to begin with.

Strangely, I'm told that the best work teams have great interview actors and/or really are groupthinkers of the highest (lowest?) caliber, yet observation and experience show the most productive teams I've seen have been fairly diverse. Maybe they're trying to select for the best liars in interviews. (Yeah boss, just like you said, groupthink is awesome!)

It's a little bit of a mis-measurement of things though. I'm not sure quality software engineers make so much more on average, it's just that the percentage of the population that are quality software engineers is much higher. It's a pretty forced selection bias since if you're just mediocre you might self-select out (note: this is just one of many reasons you might self-select out).

Age discrimination seems to be a significantly smaller problem outside of Silicon Valley. [e.g. Finance, Retail] So its quite possible they are sacrificing experience for other things they think are worth it in SV.

Except that they call it experience for a reason. I know of 2 kinds of people: one who keep doing the same things over and over again and don't learn new skills; and the other who constantly improve over what they know currently. The latter builds up the kind of experience that is immensely helpful in many technologies, and deserve the higher salaries.

I suspect a lot of companies try to save money on the short term by hiring inexperienced developers and then have to deal with the long term pains of supporting that code.

A lot of companies also try to save money in the short term by hiring experienced people from the first group who happen to align with whatever their stack is today. Then they whine and bitch about "older developers" when they try to change the stack three months later and this person can't keep up.

I would be wondering why a company is completely changing their stack after 3 months. Im in my late 30s and 9/10 times, my experience is that its for the wrong reasons.

Older and more experienced devs have a hard time seeing poor decision after poor decision being made and just following the path to failure.

Why? Weve seen it too many times and also have seen too many companies go under as a result.

I almost said "three weeks", but decided to back off on the hyperbole.

Yes, resistance to "flavor of the week" stack changes is definitely something that would turn poorly-managed companies off experienced devs. Companies still tend to be short-sighted on their experience requirements, though.

A company is only as good as its leaders. When the senior engineer in the team is knowledgeable and trusted by others in the team, it is a lot more likely that such futile efforts will not be undertaken.

It seems like ageism in tech is subject to a different dynamics compared to sexual or racial diversity.

With age comes more work experience and most SV companies (even the unicorns) usually don't need it. Most of them is driven by pretty trivial tech anyways. As soon as you start looking into technically challenging fields, you see more and more older people: Sebastian Thrun is in his late 40s, Guido van Rossum is almost 60. People like Doug Lea, Lars Bak, Martin Odersky, Fabrice Bellard, Matthew Dilon, Simon Peyton-Jones etc are all well beyond their 20s.

It makes perfect business sense. It's an overkill (and a recipe for disaster) to hire someone of that stature to build you a website. There's also nothing special about tech in this regard: if 90% of all legal work in the world could've been done by a paralegal, law firms would all be full of cheerful 20 somethings.

Hah, 90% of all legal work IS done by paralegals.

I actualy would agree with you and I should've said "99%" above.

Exactly my thoughts. You don't see a lot of twenty-something hipster types writing memory allocators, device drivers, kernels and critical middleware. Yet, the industry nowadays is dominated by people who believe that cobbling together a single-page application using the latest, shiniest framework is at the edge of tech excellence.

In my experience, a significant portion of the hobbyist operating systems community is highschool or college students, actually.

But then why do we have such a strong culture around hiring the "10x" engineer?

What I've noticed in tech is that the further you are from the [being polite] demographic core -- the better you need to be.

In the context of this discussion, there's room for you as an older employee, but the way it seems to work is you need to be really really good at your jobs. Because when you make the inevitable human mistakes, the number of years you've been at it is always brought up.

I have to wonder how much of that is discrimination and how much of that is salary mechanics.

More experienced people demand higher salaries. When I apply for a new job, I expect a higher salary than my old job, and I'll use my experience to justify it.

Typically, older people have more experience and thus ask for a salary to match. When you're asking for a high salary, companies generally want to know that you're good enough to justify that salary. Companies aren't going to put that kind of pressure on a fresh-out-of-college 22-year-old because such a person is going to be working for peanuts.

> Companies aren't going to put that kind of pressure on a fresh-out-of-college 22-year-old because such a person is going to be working for peanuts.

22-year-olds don't work for peanuts in SV. They make double the median family income in the US before stock.

Still, even with such an elevated baseline, I'd imagine that somebody with 10 years of experience can expect to make a lot more than somebody with no experience and that somebody with 20 years of experience can expect to make a lot more than somebody with 10 years of experience.

We're speaking relatively. In the context of the conversation, it makes absolutely no difference what someone working in a McDonalds in rural Wisconsin makes. We're talking about the cost of engineers. And compared to people who do have experience, they're working for cheap.

It's somewhat irrelevant how much money you're being paid between $100k and $300k.

I know from experience there's not enough free time to spend that much money anyways so unless I'm getting a part-time job or I'm trying to retire early or something it's not a priority.

After $100k I'm going to start looking at other priorities like equity, how interesting the work is, food and ping pong tables and so on. It wouldn't make any sense to further pad my 401k or whatever at the expense of my day-to-day happiness.

Depends on where you live. In the Bay Area, the difference between $100k and even just $150k is quite a bit in terms of housing.

I cannot help but think that companies dislike older people because they don't put up with that much bullshit.

You can underpay a young (naive) person, make them work 12+ hours a day, if they get disgruntled pacify them with a nerf gun fight or catered lunch. Older people might not go for gimmicks and ask for appropriate working hours and reasonable vacation time etc. That puts off the corporate types.

Completely agree. The infantilisation of the workplace is more of the more tiresome trends to come out of the startup scene.

In that case why do these people care that they dont get hired?

And the yelling/bullying. What is it with managers at startups and yelling? I got enough of that growing up. I have zero patience for it from my boss.

That was one of the bigger reasons I left my last job.

Now, I work at a defense contractor that's been around for 20 years. It's still a small company, no bigger than the startup I worked for before, but it's a much saner, more stable company, and hearing my boss's voice doesn't make me physically flinch like it did at my last job.

Yep, that I draw a paycheck from your company does not mean that I am paid to put up with your shit. I don't care that your wife is cheating on you, or your kid set your dog on fire, or your mom is dying of lupus. If you can't keep that shit at home where it belongs, then you need to stop trying to manage people because you can't even manage yourself.

I recently went through a job search and began writing off companies that were all 20-somethings who obviously didn't have a lot of interviewing skill. I would say bias against older interviewees is 100% politics. Many of these interviewers were not experienced. They knew they wanted to be top dog in their respective department,s and thought that it was in their best interest to keep experienced people out. It's not until they go through a few cycles of pain and disappointment do developers start to want to work with experienced people. It's not out of respect. It's because they now understand that they are only hurting themselves and want someone to relieve their workload. Mid-tier and experienced interviewers loved me. Early career people tried very hard to throw their best curve-balls, but I had already spent a week working problems. In the end, one company in particular, Facebook, simply just said that I answered correctly but answered too 'slowly.' I knew they had cracked when I heard that word.

'Slowly' is another thing going on in the industry, not just facebook. They want 'speed' with 'correctness'. I don't know where this leads to.

It leads to interview arms race. People will try to find ways around any sort of objective measure devised. Soon we'll have sexiness! "Your code works. You were fast and correct but just not sexy enough. Thanks for stopping in."

Let's go the the very core of this: smart old people are massively more productive than fresher minds. They know the fundamentals and they know the tricks, they also know themselves and their needs. They can tell youngsters that you are wasting your time and they are right. Point is: youngsters need to waste their time in order to learn life, the trade and -in this environment- in order to get something really new out of their own evolving needs in an evolving world. A corollary is that domain-specific applied problems are probably better suited to older people but unpredictable ways are easier to come from fresher minds.

I am going to get a lot of flak for this. This is my personal experience.

For older people, who have experience building stuff,e.g-software developers who have done some development in their life- they are worth their weight in gold. BUT most older people I work or have worked with, they are not all developers. People like sysadmins,IT people, sharepoint admins, automation managers,DBAs,Managers some system architects etc- I have seen some common traits- 1) They have no enthusiasm for work. Work is not even secondary for them. Its the last thing

2) They either think they are doing hard work or act like they work hard. Exaggerate all issues or whatever work they did even if its just an installation

3) No passion for technology 4) Do not want to learn anything new 5) Don't care about above, because its time for their retirement and so they don't care what others think

Given this, if I were building a team, I would lean towards the younger crowd. Unless the older person has experience building stuff.

>I am going to get a lot of flak for this. This is my personal experience.

Yes, you are going to get a lot of flak. I'll start. Yes, it's your personal experience. Personal experience is where prejudice usually comes from. If you get beat up by 3 people in green tee shirts, you're going to cross the street to avoid people in green tee shirts. That's the way our brains are wired. It's natural. It's instinct.

It's also natural to pee on the sidewalk when we feel the urge. But we suppress that instinct because society functions better when we do. Similarly, society functions better when we suppress our natural prejudices while interviewing. We use our intellect to remind ourselves that there are people who don't fit the mold of our personal experience, and force ourselves to interview one person the same as anybody else.

And you keep doing it even after interviewing several people who do fit the pattern you've seen previously.

You should get flak for this. If you were building a team, you would be judging a person based on a group they belong to, not the person. You would also be doing something illegal (assuming you are in the US and the person is over 40).

My very favorite interview question ever, from when I was 41, posed by a fresh UCLA grad: "do you think a gentleman of your age can interact with programmers today?"

I have been brought in, as an independent contractor, at the tail end of enough projects to "salvage" them to have a somewhat cynical point of view on this.

In all of the worst cases the projects probably had no one over 25 working on them.

I'd figure eventually enough money will have been lost on such failed projects for tech companies to change their minds on this.

As long as the industry keeps growing quickly, we'll keep seeing teams that consist entirely of inexperienced youth.

I think the only thing that distinguishes now from previous periods in the software industry is that there is less of a engineering-driven culture in the companies - product and sales more frequently take a leading role, and the technology used is cheap and accessible enough that bad developers can still make a go of it, get the business through launch and into profitability(albeit with catastrophic bugs, no security, no backups, etc.).

There seems to be some assumptions that companies prefer to hire younger people. I have yet to see that, myself (getting close to 50). When I was interviewing people, I was looking for older people with good transferable skills. We just couldn't find anyone. However, I think that there are some caveats.

When people are young, you tend to cut them some slack. You don't really know how they are going to turn out in a few years. You hire someone with the hope that they will improve quickly over the short term. When people are older, you have a track record to look at. Sometimes it is very obvious that they have had a hard time of it in their career.

The end result is not that people prefer younger people to older people, it's that they prefer unknown quantities to known, poorly performing quantities. If there is someone with an exceptionally good track record over a long period of time and who can do a good interview -- my experience is that they will be snapped up quickly.

I don't really buy the idea that length of employment is a serious issue either. Attrition in IT is huge and I never assume that anyone is going to last more than 2 or 3 years.

I think some, perhaps most of this effect is related to the growth of the industry. Far fewer 25 year olds started a career in coding in 1990 than 2015. Fewer 25 year old coders in 1990, fewer 50 year olds in 2015.

That dynamic has existed for a while. When Gates' & Wozniak's generation started coding it was an unusual pursuit. Age gaps became part of the demographics. Like everything else, being common translates into being normal.

Other than that, I think there is a little more attrition in coding. Experience is important, but current knowledge is too. SV startups are riskier, so more appealing more to younger people. They use new technology, so less of a comparative advantage for old skills.

I'm not saying discrimination doesn't exist, I'm just saying that demographics play a big role explaining the average age. Some of the discrimination that does exist likely comes from simple human pattern matching. That's not what a coder looks like. All the coders I know are 25-40.

If I'm right, time will fix this.

A relatively well known 60+ dev would agree with you: http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html

This is an underrated comment. The data is right there; even if you disagree with the author's conclusions, it's pretty hard to argue he's incorrect about the correlation between knowledge and age. Here's to hoping I'll be one of those older programmers in 15 years.

YMMV, I am 58 and I am a UI designer. In my 30's I thought I would be unemployable by 40-years-old due to exceptional "kids" in their 20's who were either as good as me but less expensive or who were better, more current, and available for the same price. This paranoia has kept me employable.

My experience is that your rate has to match the quality of your work not your experience or names of the NASDAQ 100 companies you worked for. If you are simply equal to the competition then you drop your rate. If you're better you match the rate.

It's too late and too hard to change SV/YC cultre. The Zuckerberg-wannabes have a mantra that after 30 you get slow and incompetent.

The only realistic path is by making new startups like the WhatsApp guys did and then the Zuckerbergs need to eat their words and shed some of their hard earned billions or get stomped by some old programmers.

One of my friends commented on this like this:

My friend: "You know, majority of actresses in porn are young so it make sense that it same for Silicon Valley start ups".

Me: "Start ups are not porn"

My friend: "Yes they are"

Me: ... thinking... "Yes..."

I must admit that I feel myself to be in the monority of middle-aged people who are aging kinda/sorta gracefully. That's not to brag, rather to point out that I know a LOT of middle-aged people who don't seem full of vitality and vigor, usually because of self-indulgent habits with food and drink.

I do wish that more of us were able to control our various appetites: the evidence that we might have a hard time doing so tends to accumultate with age.

This is really important, must people overlook how eating healthy and doing exercise helps. And it even makes you look 15 years younger!

Yes. 39 here and I feel better now than I did in my 20s, and I can run a mile faster now too so I at least have some objective evidence I'm not totally fooling myself. :)

I'm far from svelte today but I've really improved my life by taking better care of my health.

To everybody in their 20s: the health-related stuff you can get away with in your 20s (poor diet, no exercise) might be working for you now but it's not going to fly forever!

There are many interesting comments, but they neglect the intersections of discrimination.

To put that simply:

a) it's hard for a >30 yo white male

b) it's hard for a >30 yo white female

c) it's hard for a >30 yo black female

a, b and c are correct -- but it's several times harder for c that for b than for a.

This issue is intimately bound up with the workaholic culture issue. Older people often have families and lives and aren't interested in 80 hour work weeks, and they've also kind of wised up to the fact that someone demanding an 80 hour work week with the promise of (unspecified) riches is just using you. SV's 80 hour work week culture is about exploiting naive young people and burning them out.

If we can do something about that, then some companies might realize that someone who's been coding for 35 years actually might know more than someone who's been coding for 5.

It's all fine until you accidentally hire people whose age doesn't correlate with their experience and maturity. 2 years of getting by as a fine-tongued know-it-all impostor with mediocre technical skills is fixable with some effort, 25 years are not.

That said, there are some extremely valuable older devs out there. It's a pity that most employers cannot afford paying them an appropriate salary.

I think this is a key insight; experience demands compensation. The question I have is; when is the experience really necessary? I took a job once, I was recommended by a former colleague to the dev maanger of a fast growing company. I was one of the best developers this person had ever known (I found out later this is how I was sold). I even flubbed a couple of the technical interview questions, but was still hired at my required salary.

My work at this company consisted of maintaining an application written in framework X (where X had long since fallen out of favor). The idea was to rewrite, but due to business requirements this never happened. Had they done the rewrite, my salary and experience would have been justified, but doing maintenance on an old app? They could've gotten a green or junior dev to do that for half the price.

What lazyjones was alluding to is that time != experience. A 25 year dev veteran who has just done the same code over and over has very little experience.

I've seen this while interviewing people. Person has 5 years experience on their resume, but it turns out they really have about 3 mos. experience. They got the job, learned it in about 3 mos. and just repeated it over over and with minor tweaks. Part of the blame is the company for no growth path and part is on the employee.

To the original point. Where I work now only 2 of the 7 devs are under 30, and they will both be 30 soon. Having this level of experience lets us build things very quickly. It also lets the business side trust the dev team to usually make the right decisions on the fly.

As they[who?] say:

Sometimes "20 years of experience" turns out to be just "one year of experience, 20 times over".

Let companies avoid older programmers at their peril. The companies that do hire them will do much better by avoiding reinventing wheels, repeating the mistakes of the past, and losing valuable tribal knowledge due to high turnover rates. I firmly believe that nothing "needs to be done" about lack of diversity in work places because the penalty for avoiding candidates based on gender or ethnicity will levied slowly over time.

Interviews should be conducted online without any indication what race or gender the applicant is. Their work and expertise should speak for itself. I also think trying to find people who "fit the culture" is a terrible way to hire. On the surface it seems to make sense because interpersonal communication is half the battle, but it's usually code for "hire people like us" so even though you may try to hire more diverse people on a visual basis, you'll end up hiring less diverse people on a personality basis which can be just as bad.

Employers should ask themselves what their implicit, and/or private reasons are for preferring younger candidates over older ones, and then compare those same justifications transposed unto other well represented vs. underrepresented groups mutatis mutandis. If the reasoning is unacceptable in the latter case, why not the former?

>Employers should ask themselves what their implicit, and/or private reasons are for preferring younger candidates over older ones

Old people tend to not want shitty deals.

I read a biography of Napoleon recently and it mentioned that he recognised that older more experienced troops tender to be much better at fighting but that they were also more cautious about picking their fights - younger inexperienced troops could actually be more useful in some circumstances in that they were more likely to rush in without any concerns for the risks in an, often vain, desire for glory.

Young devs today tend to be opinionated - you can't aim them at any random target. But in reality, that doesn't change much; just pick the devs with 'right' opinion and you get the same pattern of behaviour as with Napoleon's young soldiers. Opinion != experience.

Young devs have, in my experience, have always been pretty opinionated.

That was the preferred french tactic shock attack in column is much easier/cheaper to train as opposed to the well trained british musketry.

It's why Al Queada use suicide bombers its cheap to train and does not need high quality recruits

Interesting to see the requirements for the elite Old Guard unit of the Imperial Guards:

- under 35 years of age at entry

- at least 10 years' service

- at least three campaigns (some had as many as 12 campaigns)

- had to literally face enemy fire at the front and survive

https://en.wikipedia.org/wiki/Old_Guard

I wonder what the tech equivalent is?

I'd guess some obscure teams of consultants that are known internally by big corporations, but otherwise unknown in the IT-showbusiness world. They show up where there is real work to be done, and hundreds of millions of dollars are at stake.

Most big organizations have a few of them. Sysadmins in particular tend to have operations "war stories", involving sorting out some incredibly stressful disaster. Servers on fire, company losing money by the second, that kind of thing. A lot of people found out on 2001-09-11 what "disaster recovery" meant. There are even literal combat sysadmins; I remember seeing a job advert for senior telecomms engineer in Iraq during the war, offering something like $100k/month.

Programming involves less drama, but every now and again you need the services of someone who knows the system inside out and has a collection of weird tricks that will get you working again.

> It's why Al Queada use suicide bombers its cheap to train and does not need high quality recruits

I think Al Qaeda uses suicide bombers mostly because they're hard to detect and let you strike a target with zero warning; it's an ultimate guerilla tactic. That young engineers tend to be particularly happy to wear the explosive vests seem to be incidental and not the reason for this tactic.

I agree with your French/British example though.

Right, but being unwillingly unemployed is the shittiest deal of all.

If old people have a great deal from their current employer, they'll stay employed and the number of old people in the industry will remain constant. If old people find themselves unemployed due to a reorg or startup failure or whatever, they'll take the best deal on offer - and the number of old people in the industry will remain constant.

If the number of old people in the industry is falling, I'd be interested in some statistics about where they're going.

Companies like IBM and HP are busy shedding experienced US-based staff and replacing them with relatively inexperienced but much cheaper workers in India.

I don't know how many are getting jobs, but I'd guess that a lot are taking early retirement. If so, the number of older workers is falling....

Older people don't want shitty deals, and they've seen it all. They've seen the latest fads in both the development sphere (every new framework under the sun), as well as management (think: Agile, Scrum, etc). They can smell the BS, and many have lost their inhibitions enough that they'll call out the BS. That gets them labelled as "toxic" or "not team players". Younger devs, meanwhile, will put in the overtime every two weeks when the latest, predictable "sprint" crisis occurs.

Young people are easier to manipulate. Work harder. Are more agile. Are more inexperienced so less likely to judge your idiotic CEO mistakes. They keep working when an experienced person would have bailed ship long ago. They are also willing to learn the new fangdangled crap you have chosen to implement your app in that you will have to rewrite after round 3 of financing.

On what do you base your claim that young people work harder?

They're more likely to put in the suicidal levels of overtime that many companies want to see in their employees. This isn't to say that older employees (including myself, almost, I guess I'm middle-aged in this discussion) don't work hard. But we're more likely to clock out at 5 to go see a kid's recital or to commit to non-work related plans and actually follow through instead of being intimidated into staying until 7 or 9 or 11 at night. We've been there, done that, and now we want to do something other than forfeit our lives to work.

Working harder is immaterial. I don't subscribe to the labor theory of value, so I don't care how much you sweat while digging trenches with a teaspoon, if someone else can do it with a cool, dry brow from the air-conditioned control cabin of a deluxe hydraulic excavator.

As a statistical aggregate, the amount of useful, valuable, monetizable work done by a human for a fixed quantity of effort positively correlates with the number of hours they have performed the same work over their lifetime. Even in tabletop RPGs, a level 20 character can soundly stomp a level 1 character of the same class. Why do so many people seem to think that experience only counts in games?

If young people do indeed work harder, it is probably because they have not yet learned how to work smarter, and they still have to compete with older workers. They can work harder, accept lower pay, work more hours, produce less work-product, or some combination.

Anecdotally, I know for a fact that I don't work anywhere near as hard as I did when I was younger. I don't need to.

"Why do so many people seem to think that experience only counts in games?"

That would make management look bad, so ...

>"Work harder."

"Put in more 'face time' without complaining."

There, I fixed it for you :-) I do agree with your post, BTW.

You missed out cheaper.

I can think of at least 2.

1) A young company, light on technical background, has build a castle on webscale sand. A few of the smarter young folks have become experts in this system, and get a lot of clout by solving "difficult" problems. Suddenly an old guy comes along and says "lets just use MySQL and CREATE INDEX". Basically, he's been there, done that, and realized that J2EE + MySQL will get the job done with a minimum of fuss, or that the "simplification" that comes from denormalizing carries a huge maintenance penalty.

This old guy threatens the young "experts" - if the system is rebuilt according to industry standards, suddenly they are just another dev.

2) The old guy hasn't kept up with the times, and is stuck in ancient (and outdated) ways of doing things - manual management of memory, FooBarFactoryFactory, etc.

You can't transpose these justifications onto non-Asian minorities, women, etc. A non-Asian minority or female 25 year old is fundamentally equivalent to a white/Asian 25 year old male. Nodejs is equally "close to the metal" regardless of your demographics.

Tech in 1996 was radically different - a CD ROM filled with a small subset of wikipedia was actually a huge technical challenge. As a result the old guy really is different.

On a personal note, at my current company I'm both the oldest techie and also the only techie who isn't a member of the majority ethnic group (sliced in US terms, at least). My age is a significant factor - I'm sometimes out of touch (I know fuckall about angular.js) and sometimes I'm the voice of experience (we should have a metrics server and use it for all the things). My ethnic diversity is completely irrelevant.

> The old guy hasn't kept up with the times, and is stuck in ancient (and outdated) ways of doing things - manual management of memory

Garbage collectors have been around since the 60s with LISP.

I find it amusing to see that the first language I was taught in an academic setting in 1996, Caml Light (ancestor of OCaml), is still very relevant today!

I had to write a garbage collector to get my SK combinator evaluator to run on a Unix mini (HLH Orion) in '88. Glad to see that functional languages eventually caught on though!

I wish my application to Linn to work on the Rekursiv hardware had gone a bit further though...

The HLH Orion ran garbage collected Cambridge Lisp from fairly early in its development.

I wonder if they used their fancy bit-slice technology to change the CPU instruction set to be better suited for Lisp?

[NB I am resisting the temptation to comment on the assertion that Lisp is a functional programming language! ;-)]

I think there were extra instructions for Lisp, it certainly ran the Gabriel Benchmarks faster than you would expect for the advertised clock speed. I only spent a day talking to John Fitch about the implementation and most of that was looking at his bindings to the GUI from Lisp.

Cambridge Lisp was written in BCPL which was one of the languages provided with the machine so you probably wouldn't want to completely replace the instruction set.

Pretty much everything that is "new and hot" was done in 60s and 70s with Lisp and Smalltalk, only smarter and better. Hell, even a day or two ago we had an article pointing out that React is basically rediscovered WinAPI. The old guard that seems to be behind the current trends may in fact be ahead, because they've seen how things went in the previous iteration.

As the saying goes, every field learns from its history - except software development.

This is true only for a very narrow set of "new and hot". Lisp and Smalltalk did not "do" the modern, statically typed, inference and category theory heavy languages that are rapidly growing. Dependent types were not "done" in Lisp/Smalltalk.

There are also a lot of "new and hot" things which are not programming language features at all - e.g., the lambda architecture, the rise of bayesian inference, and other such things. Even relational databases - so old that it's easy to forget they were "new and hot" (with good reason).

> statically typed, inference and category theory heavy languages that are rapidly growing.

All of this is quite old too. As I said, I learned ML as an undergraduate in 96, 20 years ago. Back then, many "hackers" laughed about such languages.

Actually, that's why I think a more foundational CS curriculum is a good thing, as opposed to those that are heavily based on technologies.

> The old guy hasn't kept up with the times, and is stuck in ancient (and outdated) ways of doing things - manual management of memory, FooBarFactoryFactory, etc.

Interesting you brought this up, because I've noticed two different approaches to this from older developers. One group is exactly like you describe, still tracking every single precious byte their code uses.

The other is like "my first PC had one megabyte and cost $3000 so don't tell me I can't allocate half a gig to this process here's $5 just go buy some more RAM!!".

I guess it's a little bit of both. First PC was $3000 (80286-16) and had 1 mb ram.

What is held over from the old days is efficient code. Not just big huge blocks that are unknowns. Ability to profile and REALLY debug, particularly profiling. Each cycle counts as much today as it did then. Seems most newer programmers were never taught that. Even web code at scale need to be clean and quick.

>The old guy hasn't kept up with the times, and is stuck in ancient (and outdated) ways of doing things

That dovetails nicely with "culture fit", and both points are also unfair and possibly untrue stereotypes. So I wouldn't count them as counterexamples to the above maxim.

This claim might be right or wrong (I've seen cases where it's true and cases where situation (1) is portrayed as (2)), but the point is it's not analogous to non-Asian minorities or women.

People complain that old guys program like they never left the 90's. No one complains that an ethnically Mexican person never left Mexico, or that someone "programs like a girl".

The only code related ethnic stereotype I've ever heard is about Russians/Ukrainians/other slavs; a lone wolf writing efficient, high quality, extremely monolithic code, usually in a non-trendy language (PHP, C, C++, sometimes Erlang or old school Lisp).

I'm not sure that's a good comparison. I can think of lots of cases where there isn't a comparison.

For instance, "More experienced people are likely to look down their nose at company culture" doesn't really have a comparison with any other protected class.

Zuckerberg saying "Young people are just smarter" seems like an instance of https://antidem.wordpress.com/2015/03/31/glantons-law/ Age discrimination exists because most of us have direct experience with family members who diminish as they age, especially when these family members didn't keep up a habit of doing intellectual intense things they did when they were younger and instead spend increasing amounts of time watching sports and doing crosswords. It's possible to be a badass programmer in your 80s, Knuth will be one soon, but it's very rare. We thus shouldn't expect to have an equal distribution of old people and young people, regardless of whether that's desirable or not.

There's certainly ageism in Silicon Valley, but if we magically got rid of it tomorrow it's not like startups would suddenly be flooded by applicants my age and older. Most older people select themselves out of Silicon Valley because most older people have lives outside of work, and they're not going to put up with the inefficient and pointless lets-all-work-twelve-hours-a-day bullshit you so often get from entrepreneurs and coworkers in their mid-twenties.

If we really wanted to achieve age diversity in Silicon Valley, we'd not just have to get rid of ageism, we'd have to change the work culture to something a wee bit more rational - and that's just not going to happen as long as all the major institutions glorify overwork to the point of burnout.

1. From the article: Age discrimination is one of the last places left where employers can discriminate. This sounds to me like we need to reform some discrimination laws at the federal level.

2. I think that we need to go to a single-payer health insurance system and get employers out of the business of providing health insurance. If this were done, more employers would consider people over 50. The ACA helps in some ways, but is an incomplete solution as the employer still has to offer and pay up for health insurance, and older engineers are going to cost more in premiums.

> I think that we need to go to a single-payer health insurance system and get employers out of the business of providing health insurance. If this were done, more employers would consider people over 50.

I've always wondered if small businesses would be more interested in hiring women in their 20's and early 30's if single-payer was a thing. The difference in health insurance costs is non-trivial because of possible maternity costs.

I have noticed in other industries they at least try to come up with stupid rationalizations why there is age discrimination and gender pay gap. The reasons stated being older people raise the price of benefits and are closer to leaving workforce. Females may leave the workforce to have children.

But in the tech industry we give reasons like old people are slow/stupid and chicks just don't understand computers like males... seriously I have actually heard that come out of people's mouths.

Its completely disgusting.

I've noticed young people are very biased when interviewing older candidates. It's kind of sad. On the other hand, older interviewers are used to hiring college grads.

Relevant article from a few years ago: http://medriscoll.com/post/9117396231/the-guild-of-silicon-v...

That blog was also the reason that someone started this Twitter account: https://twitter.com/neckbeardhacker

I am a member of the early 40s club. I've had what you call an interesting career. I have delivered technology solutions wherever I have worked and they have on the whole been pretty successful. One of my dreams is to work in Silicon Valley and I have no doubt that I could be successful. However, it's not a goal I am pursuing for various reasons, one of those reasons is the perceived age bias that exists there.

I run a design/development agency in Europe. I'm the only male (of <10 employees).

We had an applicant for a development job who said he was 50+ and had been self-employed several times. In the end we decided not to hire him.

The age was a factor, but not in the way you'd think. The primary reason was that he proved himself to be a very bad fit for the team and the kind of clients we work with. He attempted to dominate every conversation to prove his seniority (or assert his potential if it was on a subject he had no prior experience with).

I'd like to think his age wasn't a factor at all and most of his behaviour can instead be attributed to his prior experience being self-employed, but I'm not sure whether this is true or not.

I don't think age is a valid argument any more than race or gender but I'd like to think that these are just unfortunate proxies for the actual reasons companies don't want to hire candidates. I've turned down a lot of "foreigners" because their language skills were insufficient for the requirements of the job. I've turned down "men" because of their macho-like behaviour towards the women on the team and I've turned down "old people" because they treated younger team members less respectfully.

None of these traits are representative of all potential candidates in each group, but they tend to be common enough that you tend to become more sensitive to them, especially when hiring people from that group. This leads to unfair bias, but short of anonymizing CVs (which can be extremely difficult) I don't see any fool-proof way of avoiding that.

There's a very thin line between due dilligence and unfair bias.

Discrimination is so popular because it works so well. As mentioned, there are cultural values that you can quite often predict just from {being a woman/black/old}.

A primary mechanism to combat this is, to get folks to evaluate each person as a person. To do this, an effort has to be made to recognize and cancel out any preconceived notions may have been formed from incidental cues like age.

I'm glad to see anecdotally that candidates were turned down for real reasons, at least so far. I'd advice being very diligent at continuing to require real criterion in hiring decisions. For instance, anonymizing CVs is not at all hard - why consider it a last resort? E.g. put a piece of tape over the name when reading a pile of them.

This is actually a big problem with deep machine learning based algorithms: they're guaranteed to be discriminatory but there is no obvious mechanism for making them obey laws that prohibit discrimination (which often means they get away with it based on a technicality).

In a perfect world this wouldn't be a problem because you'd just fix the root issues (i.e. eliminate poverty and crime in ethnic groups, fill leading roles in tech with women, etc etc). In the real world, things are not that straightforward (especially in the US where a lot more data can be collected and used to feed the algorithms than elsewhere).

I was looking over resumes 2 years ago. We saw a guy in his 50s. My boss's immediate reaction was "he's 50?! wtf? so old!"

Ageism is real folks.

> In comparison, the average age in more traditional tech industries like data processing or web publishing was almost 10 years higher than Silicon Valley/Internet firms.

Maybe this could be explained by younger folks, not bound to a family's worth of obligations, moving to California in droves from places all over the world?

So maybe we should normalize the data based on the age distribution in silicon valley.

I'm not a fan of "protected category" hiring rules in any case. If good old people are underpaid, then let your company profit by hiring them. I suppose a tempting compromise is to not allow companies to solicit disclosure of age etc (so people can leave the year off their degree, show only most recent experience, etc), but honestly I think it might be better if those companies that really will only hire young would advertise the fact and save everyone some time.

Starting from only a very small real disadvantage in ability, any externally distinctive group can quickly seem a 'market for lemons' - for example, maybe the oldsters you've seen so far across the interview table are unrepresentatively bad, because the good ones are working and not interviewing. So don't think because you've seen 4 weak candidates of 50+ years old that it's not worth looking at the next.

Age diversity will be "achieved" when young developers start valuing themselves properly, i.e., never. That whole nonsense of "culture fit" is really just a euphemism for won't fit into a culture of exploitation and extraction. You would also get a "not a good culture fit" if you had young devs who respected their time and drew limits. That's the thing about the abusive environment in the tech sector, you are only valuable if you are willing to do the modern equivalent of back breaking work to the point of exhaustion. Sure, it pays off for some ... usually the founders ... but for the vast majority it will not pay off and they will simply be left with having spent their young years hunched over laptops day in and day out in order to make others rich. It's the modern equivalent of the gold rush and young devs are the mules and hard laborers.

What's most interesting to me is, after reading the comments on this article, very few people are coming back with "but why do we need age diversity? What if old people just aren't interested in working in tech?"

Swap out gender for age, and you'd see a whole different weight on the spectrum of replies.

In my company, it seems we are (slightly) biased toward female programmer/researcher candidates (that is, a female will get hired more eagerly, all else equal).

I wonder if the technical interview process can feed into this too. Particularly the questions straight out of the final year of a computer science degree. It'll be decades since senior engineers left university and they reasonably wont have held on to the knowledge that they haven't used.

I'm in an industry where most of the analysts are 40+ and many are in their 50s and 60s because the clients only want experienced developers / business analysts. It's a niche market that a new-hire would have a tough time getting into. It works both ways sometimes.

I would like to take this as an opportunity to ask:

Why is diversity important? e.g. in age, gender, race, ?profession? ... etc. Isn't the business built on the advantage of particular "group"? And that skill becomes be-all, end-all (e.g. important) to the success of the company?

If you develop a product in a monoculture you are at risk of getting wiped out by a product that has features that appeal to people other than your minority. This summer the US Census published that there are 50.2% children under 5 years old who are minorities. Diversity is it's own reward because no matter how smart you are someone with a different background than yours will bring solutions to problems you would never have thought of.

When all your constituents are the same size and aligned in the same direction, your aggregate material becomes very strong, and hard, but it also becomes brittle. Diamond is 100% carbon, all bonded via identical sp3 hybrid orbitals. It is very hard (10 on Mohs scale), but it also has perfect cleavage in 4 directions. You can cut a diamond in half with a light tap in just the right spot. Diamond cannot be effectively carved, it can only be cut into faceted gems.

If you incorporate materials of different sizes and orient them in different directions, your aggregate material becomes very resilient. Nephrite has many interlocking fibers of tremolite and actinolite, like the hairs in felt. Nephrite jade can be carved with exceptional detail. A nephrite bell or war club is reasonable, whereas trying for the same with diamond would be insane.

When your workforce lacks diversity, you are counting on its resulting strength to accomplish some goal before an unexpected shock shatters the organization.

Or perhaps you can look to the banana. Most bananas in cultivation are clones from the same stock. Nowadays, the variety is the "Cavendish". But the banana on store shelves used to be the "Gros Michel". Panama disease wiped them all out, because they were all the same plant. No diversity means less resistance to external hardships.

Cheetahs are so similar in genetics that regardless of numbers, they are just one disease away from extinction.

So while similarity does produce better focus on positive goals, diversity is what insulates you from negative shocks. So the natural conclusion that you an I may reach is that companies which lack diversity are looking to grow as quickly as possible and seek a fast exit before their first crisis hits, whereas those that hire more broadly are in it for the long haul, being more able to weather unexpected adversity.

Does anyone know of any statistics that show people in the tech industry by age? In other words, I wonder if the sheer number of older people "in tech" is just dwarfed by young people who have been in it all along (As opposed to a career change by a mid-career older person). Also, since the tech industry has grown so exponentially, the number people in the industry in and of itself has expanded to greatly include younger people (versus existing, older people who choose to switch into the field).

This is to say that I wonder if people older than 40 or older than 50 are truly underrepresented in tech because of age discrimination or is it because there is, quite literally, not that many of them in tech to begin with?

It seems like the biggest issue here is the compensation structure of startups. People who have been working for a long time are those least likely to take a huge pay cut for upside even if they're the people who are often well-suited for that risk.

I don't think this is possible in the short term. There is probably age discrimination, sure, but to a large degree the problem is that programming is a very young field. It has been growing at a rapid exponential pace for decades, which means that the vast majority of people in the field have been in it for less than a decade.

The only way to increase the stock of older programmers in the short term is to convince people who are fairly far along in their careers to jump ship to a new field, and start off from scratch. Daunting, and likely a step back careerwise.

In the long term, the problem will likely solve itself. Assuming that you actually consider it a problem.

It would be very interesting to see when the millennials, people born particularly in the 90's get to their 40s.

One of the reasons for the lack of diversity is that people born before 1975 haven't really experienced the internet revolution like those of us born in the 80s and 90s have.

Sure there are exceptions, those exceptions are people who were directly working on technology. An alarming trend in our industry (at least in my part of the world) is that a lot of people stop directly working on technology by the time they are 30-35 and start going towards the managerial end of thing.

"One of the reason for the lack of diversity is that people born before 1975 haven't really experienced the internet revolution like those of us born in the 80s and 90s have."

One reason for the lack of diversity is that people make generic assumptions like this.

and some of us will have seen precursors to the internet do the same things eg Prestel/Videotext :-)

I can remember reading the original news posting about NCSA Mosaic and wondering "that sounds great - but what's the fascination with loading documents over a network?" :-)

I can recall finding a text mode www on the ITU's gopher server and thinking interesting :-)

And I can remember when you could quickly skim the whats interesting on the www today.

Actually we experienced the internet revolution. You just had it presented to you on a plate.

In in my early 30's & on a knife edge, balancing between management and development (from a development background) - I'm now in a quite senior role for a product at a medium sized software company.

I'm finding it incredibly fun - being be effective on both sides - I really do feel it is a false dichotomy.

I'd suggest that there's the possibility that computer programming and computer networking technologies will be just as different from now in the future as they are now from the past. That is to say: although things are smaller, and there's more room for code and data, only the appearance and presentation (e.g. Vocabulary) has really changed.

> One of the reason for the lack of diversity is that people born before 1975 haven't really experienced the internet revolution like those of us born in the 80s and 90s have.

What does that even mean? We lived through the Internet revolution. And even we can't claim to have invented it, because that was the generation before us (Tim Berners-Lee, Vint Cerf, Bob Kahn, etc).

It's exactly because of this kind of mindset that it's becoming increasingly hard for 40-somethings to find decent employment in development, and (along with corporate culture) a strong factor in the trend toward becoming managers once we hit mid-30s.

You're going to find the next 20 years enlightening, that's for sure.

> What does that even mean? We lived through the Internet revolution.

I was born after 1975 (barely - the Internet revolution happened when I was in high school and college) so I'm not just sticking up from myself here when I say that a lot of people born before 1975 really do "get it."

Almost anybody who spent ten minutes using BBSs in the 1980s knew that some kind of connected thing was going to be the future. It was nearly inevitable. Maybe it would have been a bunch of closed CompuServes and Prodigies, maybe it would have been a BBS in everybody's home, maybe it would have been something global and semi-mostly-kinda open like the Internet. Whatever the form, that generation knew that connectedness was the next logical step. You can see it in sci-fi of the era (Neuromancer, etc) ...they weren't sure what form or forms it was going to take, but everybody knew (hoped) we were going to be connecting to other people using our computers.

So a lot of people from that generation were right at home once the Internet became an everyday thing. And a lot of them weren't, obviously, but a lot of them were totally primed for it.

> One of the reason for the lack of diversity is that people born before 1975 haven't really experienced the internet revolution like those of us born in the 80s and 90s have.

Speak for yourself. I saw an IMP get installed in 1986. And converted a business and it's products from SNA to TCP/IP. And worked at one of the first profitable SAAS companies when they were called Application Service Providers.

If you were born in the 80s or 90s the internet revolution was already over by the time you started using it.

Discussions of workplace diversity try to answer the question "Should Alice or Bob get the job?" That doesn't sound like the right question to me, because one of them is still left without a job. Instead of 30%/70% unemployment, you've achieved 50%/50%. That's nice, but...

I think we should try to create a baseline of happiness that no one can ever fall beneath. Universal basic income might be a good step in that direction, though I don't expect it to solve all the problems.

I agree with you that what you say should be the main goal, but I suppose it's also worth to redirect some spare energy to optimize the current state of affairs (as long as it doesn't go against the main goal you mentioned).

> Giving good jobs to everyone

Whether they're qualified or not, right? Because there are not enough jobs for everyone, and most people are not qualified for most jobs.

Everyone slaving away is not anybody's idea of Utopia. Once upon a time, we thought robots would take the yoke from our shoulders and leave us all more creative and happy.

Automation is fast approaching something like that vision. But now any time we talk about universal income or other such programs, it turns instantly to make-work projects. How can we keep the slaves working? Because, if I work, everybody has to work.

Maybe there's a bit of misunderstanding here. I'm a longtime supporter of universal basic income with no strings attached. But basic income or not, people with jobs would still have higher self esteem and would feel more valued by the community. So I'd vote for a universal job guarantee as well.

I think people tend to exaggerate the problems that can be solved by their favorite idea, and discount other problems. A good utopia should address all of people's needs, not just the material ones. The need to be needed is a particularly tricky one to solve.

I'd be glad to give BI a try. I'll take that risk. I'm not so sure of the idea I'm more comfortable at some made-up job that somebody else thinks I need to be fulfilled.

Don't imagine for a millisecond that the only way I feel needed is because of some bs job.

I think you missed my point entirely. I'm not advocating for make-work at all (quite the opposite).

I'm saying that 100% employment is a dream and not sustainable, and probably not even economically beneficial. There are more low-skill workers than there are low-skill jobs, and there are fewer high-skill workers than there are high-skill jobs.

Don't want to step on toes, but in short - you can't. Part of the problem is the age genius/criminal curve which shows you the productivity of a typical male, another part is that as you age there is only so much more bandwidth left for grinding shitty jobs and boilerplate code. The only solution is to own a dev shop by that age, otherwise you're f, excuse my bluntness.

Do something about housing costs? Living there with a family is an extremely expensive proposition. I suspect a lot of people my age (40) simply don't want to be there. Here in Bend, I live 10 minutes from work by bike, have all kinds of great outdoor activities year round, have good schools for my kids, and the median price for a house is 350K - which is actually kind of expensive for Oregon.

Management will always want to hire the young ones simply because they are easier to control and have lower salaries.

It would be great if this starts to change as the swell of tech workers hired to work on internet and mobile products in the past 2 decades starts age into their 30's / 40's / 50's.

I wonder how much of this discrimination is due to housing inequality. I suspect many young programmers resent paying $3500 a month rent to a landlord who bought their property for 75k 20 years ago. Denying jobs to that generation might be their way of fighting the perceived injustice.

As a side note, I do dislike anti-discrimination laws. As an example, one of the ways to enforce it is via statistical analysis. I have a feeling this probably works for certain kinds of jobs but not for others.

Won't this happen naturally as millennials get older? More people are studying CS and going into tech these days.

I'm 51 and have never had trouble finding work. Stay current, relevant and, most importantly, specialize.

I wouldn't join any club that would have me as a member.

   -- Groucho Marx

it just goes to show, everyone will whine when they see people getting things they want.

Will you do any less when it's your demographic's turn to be deprived?

Maybe start at YC first?

Except that YC is a very particular style of incubator: They're a growth incubator that pushes companies to grow fast over growing well. On the contractor's triangle (good/fast/cheap, pick any two), they're all the way over on the fast/cheap line.

More experienced people tend to see the value in growing well AND fast at the same time. So more experienced engineers (aka, older folks) tend to always push away from the cheap and towards the fast/good side of the line ... or if cheap is a mandate, then they push towards the good/cheap side of the line.

None of that is what YC is about.

"They're a growth incubator that pushes companies to grow fast over growing well."

Any evidence for this comment? Any evidence that there's even a tradeoff you can make? Any evidence that your hypothesis (which seems to be that "growing well" is better) is supported at all?

The reason (just guessing, not affiliated with YC) that YC feels like growing fast is best is that "growing well" might involve a greater investment before you've reached product-market fit.

I will also add that age-diversity has almost nothing to do with founders. Founders are already slightly older on average. Plenty of companies founded by young founders have their average age go up quite a bit once they have found product-market fit and can hire more people.

YCs bootcamp style tends to select recent students without families. Older marrieds have made it through, but are not the majority. (Based on reading Stross's YC book.)

I am not familiar with Stross's book. If I remember correctly this subject is not part of the YC application (marital status, family...). I have applied three times including the latest for w2016. I have not been invited for an interview yet, so maybe it comes up in that context. For the record, I am single, no family, former aerospace engineer, laid off in my early to mid-fifties, several years ago. The topic of age diversity is of great interest to me. I believe there is a lot of engineering talent and experience laying dormant, waiting to be tapped - people laid off right before retirement. Adding to my defense systems engineering skills I've become a full stack developer for the project I am applying with, and I am ready to go!

(edited for typo)

Lack of diversity, measured in any way, is often tied to folks laden with insecurity or a lack of empathy, ending up in a position to impose their lens over others, to the point where it becomes systemic.

At least changes for the better are needed.

Defining what good citizenship is for everyone in tech, and through it, expecting diversity from management first, then downward.

- Diversity is bullshit if it's not reflected and practiced from the very top management to the bottom. When people wax diversity I check the management and it tells me everything I need to know. You put up, or shut up. I applaud guys like Eric Ries for doing the uncomfortable and succeeding. Diversity needs to rise to the levels of decision making, and replacing them with standards of good citizenship that applies to all is what's needed.

- Being a good citizen in technology community needs to be the core of being in the tech community. Maybe this is missing in tech culture, presumably because it's so new. What will happen to the young people who look down on others? They're screwed because the hurt train they build is coming their way in 10 years.

Transforming into a culture where standards of good citizenship apply to everyone, will need everyone to be equally comfortable and fluent in having open minded conversations about diversity that might need us to look at ourselves in the mirror.

Then, with awareness, disrupting the lack of diversity, breaking cycles of discrimination.

In my experience of being a member of multiple minority groups in tech, I have learnt and try to remember:

- People who don't want to work with you will find any reason. That's what's important to focus on, not the reason. You got every shot to make something better to make jerks into dinosaurs. It's good to flush the turds out into the sunlight whenever possible, good citizens will always be supportive of this for the greater good.

- Innovation doesn't live in a mindset of doubts and seeking permission from others. You're not an entrepreneur until you stop asking permission and validation. People who are givers and truly focus on adding value will do it unconditionally, as long as you focus on being someone who focuses on adding value.

- Rather than become radicalized and negative, you may have no choice but to become 8x as good as the average Joe. Your perceived gatekeepers can become your slaves by pushing you to push yourself. If you feel you have to be 2x as good to get half the respect, 4x as good to get equal respect, and 8x too good to be ignored, you get to write more of the script. It's not fair. Nothing worthwhile seems to be. I measure equality in society by what the average joe can access, so by that definition this point fails, but I've selected pursuing improving my abilities beyond what others can squeak by with in the hopes that the future will have more diversity minded people at the top.

Many do not practice discrimination, but benefit from an existing benefit of being a demographic that systemizes it. Becoming aware of the things you never notice is the first step.

Thing you can do nothing about, your age, gender, the family you're born into, where you are born, the color of your skin shouldn't define your opportunities, potential or abilities.

It starts with the majority of people on this site and in our community.

What do you commit to do to become a better citizen of the tech community for diversity? I know I'm sure as hell doing everything I can because I'm on the other end of it far too often.

As a person on the wrong side of 30, how can you live with yourself pandering to 20 somethings? I've watched over the years my 40 something coworker do this and it's the most pathetic existence I can think of. It's no surprise he sees a therapist weekly. And yes ladies he's single and ready to mingle.

I think there's a difference between "pandering to" and "relating to". The former refers to artificially trying to fit into and build trust with a group, usually with an ulterior motive (e.g. you want their votes). The latter refers to the ability to take yourself out of your own "box" and make an effort to understand them and find some common ground with them.

And guess what: the attitude you demonstrated is the exact same attitude you blame young people for: you're refusing to adapt to them because they don't fit your own age-defined tastes and characteristics.

I'm 30.

I'm also happily single and childfree, and a lot of my hobbies are more common among young people. I watch the same movies, TV shows, etc. as people in their teens and twenties. I voraciously read comic books.

I don't expect any of that to ever change. In a decade, I'm going to be consuming the same kind of media in my 40s that I consumed in my 20s and am now consuming in my 30s. Being childfree is never going to change (especially considering I voluntarily sterilized myself), and I'm mentally incapable of feeling romantic attraction to anyone, so I'm going to be single for the rest of my life.

It's not pandering: it's simply be being the kind of person I am, which happens to mean that, on average, I relate more towards people younger than me than to people my age, and that discrepancy is only going to get larger as time goes on (mind you, the "on average" is key because I've met and get along with some fellow outliers, not just my age but also older than me).

Oh my :/ I don't know you, but this sounds grim.

What's grim?

I love having freedom. When I say "I'm going to be single for the rest of my life", I don't mean it in a sense of resignation like "aw bummer, I'm going to be single for the rest of my life, this is gonna suck". No, I mean it in the sense of "yay, I'm going to be single for the rest of my life, and it's gonna be so awesome!".

Same with being childfree.

I have the freedom to do anything, go anywhere, and enjoy my life for myself, and I love it.

I'm basically an overgrown kid, with the only difference being that I get paid to take my toys apart, find out how they work, and put them back together in new ways, which I've always done for fun. I love it!

And, hey, my cousins have kids, so I get to be the cool aunt without having to actually spend my life taking care of anyone.

That might really suck in your 60's. Age has a way of happening to us regardless of our preferences and expectations.

"Being childfree is never going to change (especially considering I voluntarily sterilized myself), and I'm mentally incapable of feeling romantic attraction to anyone,"

Well there you go. Ageism problem solved. Just don't have kids or feelings. JFC

Oh, I have plenty of feelings. I have lots of people I care about and lots of things I feel strongly about. I love spending time with my friends, and I deeply care about their well-being; I just can't feel that particular way about people.

What it boils down to is that I have absolutely zero interest in taking part in any kind of romantic relationship. The idea of having an SO, or worse, living with one, is actively repulsive to me.

The technical term is "aromantic", which I've begun to shy away from using because too many people like to make puns on "aromatic" whenever I say it.

I haven't had a TV since I was a freshman in college and rarely went to movies. It obviously never interfered with my work. Now, after decades of experience, not knowing the latest TV and pop-culture becomes a critical culture fit issue. Interesting extra hurtle in a "meritocracy"

>It's no surprise he sees a therapist weekly. And yes ladies he's single and ready to mingle.

This kind of adhom is just not needed.

We detached this subthread from https://news.ycombinator.com/item?id=10413154 and marked it off-topic.

Reply on news.ycombinator.com