We only hire the trendiest

poker face - is super cultural thing, I work with several Asians, most of them (not all!) sits _with_ poker face whole day. It is kind of hard to read people and understand if they got it when I'm explaining something. They are not even nod or smile. I'm European and sometimes it is super frustrating to not receive any body lang feedback. But when we close office doors they starts to chat, nod, laugh and what not.

On other hand there are two Japanese who acts like Europeans all the time - nods, talks, etc even though they left Japan ~2-3y ago. I thought initially that they already adapted to this Western style.

I've talked with them all about this and they just said that they just do what they did in their countries.

I didn't mean to call you a liar. You might believe you are screening for and prioritizing productivity. I'm saying that I don't believe that's actually what the hiring process you're a part of is screening for, even if the people who comprise that process believe it. Obviously, this is just my prior opinion, a default, since I don't have special evidence.

Regarding your comment, the most major issue is with that term "lean." In many cases, this means some usage of Agile/Scrum nonsense, which if true completely throws out any credibility that the position is focused on productivity in the least bit. Sometimes instead of Agile, "lean" is used for six-sigma like micromanagerial process, which suffer all the same criticisms as Agile.

Even in the best case, a team that self-identifies as "lean" is failing to make use of specialization of labor. Many of these teams hire people into roles titled "full-stack" or "generalist" and they say stupid shit like, "because our team is lean, you will have to wear many hats." (I am actually so sick of hearing the phrase "wear many hats" that it causes me to instantly reject a job out of hand at this point).

"Full stack" is arguably the single worst trend in all of software. It goes completely against the major benefits of software development: specialization and separation of concerns. Many organizations that use full-stack practices also believe that they don't need to provide meaningful job descriptions. They want to leave job descriptions vague ("many hats!!") and argue that candidates have to be adaptable if they want to cut it in this crazy dynamic world of ours.

This is all total bullshit. There might be a small period of time in a start-up life cycle when it pays to have many generalists and leave everyone's work assignments vague. But most start-ups, and certainly most established companies, have no business operating in "lean" mode. You need to empower employees to know the limits of their job descriptions, so that they won't be treated as catch-all, pan-everything work receptables who are capped solely by the literal limits of their physical exhaustion (at which point you whip together another pan-everything job ad to hire yet another generalist to handle the undifferentiated work overflow).

This fails to respect the worker's speciality (which is something the worker absolutely had to protect to advance in their career). It also means the company is not extracting the full value from the worker that they could by doing the challenging job of actually managing them and setting up the workflows so that work requiring that specialist skill is routed to the right worker. If the company embraces a "full-stack" "we're lean so everyone wears many hats" attitude, it's an overt admission that the company couldn't give two shits about what you're actually capable of doing for them, and instead only cares that you do what they happen to tell you to do right now, even if it's hilariously underutilizing you or is hilariously inappropriate for someone with your particular skills, or is using in a way that fails to address critical business needs you've identified.

Basically, I see "lean" and I immediately think, "managers believe they can throw a bunch of so-called full-stack developers on a Scrum team and then flip on autopilot." The managers are going to get mad if that machine learning expert they assigned to clean up the legacy Rails codebase ever breathes a word of dissatisfaction over not being fully utilized or utilized in their speciality.

"lean" is by far the buzzword that is most negative from your comment, but I also see the phrase "move the ball forward" and I immediately picture those trite motivational posters with eagles and someone passing a baton in a relay race and I just roll my eyes. We're not in middle school. We go to work to do work. We can speak about the work we do in grown up terms. Not "moving the ball forward." To me, this communicates a very top-down attitude about what progress means. There are some high-level, likely paternalistic or even misogynistic, ideals about company progress and what a good little worker must do to be productive. No thank you! Even if this language is not indicative of the worst kinds of problems, it still is extremely infantilizing.

"A single unproductive developer ..." oh boy, don't even get me started. Right away this sounds like someone with a way over-inflated opinion of the work their team does. "Our work is so very important that we can't abide even a single person who isn't amazingly productive." Yeah, OK. For one, you just said your team is lean, so whose fault is it that you don't have adequate redundancy built into your technical resources (your tech staff). If someone said their distributed database "couldn't tolerate even a single node failure" you'd ask them why they don't create more nodes and add redundancy to have a safety factor.

Why would a team agree to be lean if they are also worried that a single bad link in the chain will cause a problem. Either there's some kind of extreme budget constraint, or else this is someone who just read a Malcolm Gladwell-like pop book about "lean" and "Agile" and decided that's the shiny new management thing they just had to have.

Lastly, I'm not sure why "release date of a feature" was the example you chose to go with. This could be innocuous, but more often than not when I see people who think in terms of release dates and features, it's a huge red flag. Most teams need to actively constrain the set of features they agree to support, tell customers and internal business stakeholders "no" way, way more often, and address overall technical debt and architectural quality concerns far more than shipping features. If I was in an early interview stage and someone is already asking me how I make sure I always cram out all the features on time, that's a huge red flag of a dysfunctional process driven more by short-term business managers seeking bonuses that are tied to on-paper accomplishments (e.g. we shipped X,Y and Z) than the engineering reality (X, Y, and Z were technically delivered 'on time' but they suck and now everyone's asking for W which we can't even do because of how fragile the implementation of X, Y, and Z was to get it out the door on time").

Let me qualify all of this by saying that yes, absolutely, 100% this sort of detailed dysfunction can be inferred from very small amounts of buzzwordy HR text and job ads. I've seen it time and time again, and even been part of the teams responsible for drafting job ads and seeing first hand the thinking processes of HR as they inject all of this awful stuff into it.

There is even a major qualitative social science study about exactly how this kind of vague, symbolic HR-approved linguistic atmosphere is heavily, heavily related to the skewed ethical views held by executives and managers. I strongly urge you to read it if you have not already:

http://www.amazon.com/Moral-Mazes-World-Corporate-Managers/d... >

I'm not saying that this definitely applies to you (I don't know you). I'm saying that my experiences tells me that the odds are that the team you are representing to "move the ball forward" with a "lean" team that cannot bear "a single unproductive developer" is a very dysfunctional one, and that many of these buzzwords actually imply the opposite of the image they are invoked to create.

I don't believe in this at all. Some of the most effective people I've worked with were people that quietly worked in their own space for 4 hrs before lunch and 4 hrs after lunch. Some of them socialized with coworkers after hours, some didn't. At least in engineering field I don't believe it is important to be that open with people unless maybe you're in sales and need that social vibe all day to keep in state. Engineers can be highly effective staying in their own space unless communication is required and omitting the usual everyday small talk BS that wastes 1-3 hours of your day

Not everyone wants to be your friend, but everyone SHOULD want to work together towards a common goal. The trick is in getting the two parties involved to see that common goal and why it's in their own best interests.

It sounds like the person you're talking about was using the conversation not as a way to acquire help, but rather to demonstrate that he didn't need it, probably in an effort to boost his own status in his social group. You're better off not working with that type of person.

Exactly. I realize now that the term "poker face" came across as too literal, and what I was really trying to describe was exactly the sense of caginess or unwillingness to put one's self out there.