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

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

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

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.

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.

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.

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.

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.

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

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.

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

Beware of hypocrites abusing "diversity" for PR reasons.

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

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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

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.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 always refer to those who have earned an MD as 'physicians' or 'surgeons.'

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

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.

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.

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). :( :(

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.

After all, they grew up with the series.

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.

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.

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.

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

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

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.

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.

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

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.

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.

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.

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

But it's certainly not the same as "OOP was invented in the 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.

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.

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?

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

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

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

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.

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

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.

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.

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

There's a relevant recent article on HN:

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

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

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

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.

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.

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.

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

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?

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.

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.

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.

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

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 suppose it's more art than science to not appear to be staring but to be blinking less often.

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.

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.

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?

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.

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

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.

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.

That works after you have the job, not before.

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.

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

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

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

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

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

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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?

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

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.

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.

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.

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?

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're right, phone screens usually get them, but not always. A fair number can still make it through.

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

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

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

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.

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.

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.

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 think a lot of this comes from insecurity by the interviewer and the interviewer's need to feel smarter than the interviewee.

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.

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

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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?

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.

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

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.

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.

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.

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.

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.

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

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

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

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

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.

  public class Person{

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

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.

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?

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

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

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

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

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

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

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

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

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

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

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

> but he's just too comfortable.

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

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

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

But thats just how I read it.

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

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

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

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

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

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

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

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

Thank you for sharing that quote.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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