Hacker News Reader

Comment by DavidWoof | Hacker News Reader

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.

View on HN

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.

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.

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.

> 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.

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.

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.

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.

> 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?

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.

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.

> 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?

Reply on news.ycombinator.com