Hacker News Reader

Many people seem to totally lack the capability of understanding simple questions. I often have to ask yes/no questions, and even then I have to say "please answer yes or no". Then I have to go beating 1 bit information at the time...

In my experience of sometimes being on the other side of these conversations, the problem is that the person asking for ‘yes/no’ answers is exhibiting a lack of understanding of the subject being discussed. They are asking questions that are not relevant or perhaps even misleading. I’m struggling to get them to stop focusing on irrelevant or wrong things, and listen to more background information that’s required to reach a base level of shared understanding.

You can do that by interrupting and asking them questions. The place to teach them is not by trying to backdoor what you think is important into the answer to some other question that they are asking. They will feel like you're being deceptive, because you are.

You are making a lot of assumptions there and seem to think that this happens to me all the time. I don't have this problem in most conversations.

To the point you're saying without the seeming antagonism - yes, you're right, a quick "wait, I think we need to talk about the background here because we're both making different assumptions" can and does work in most conversations with most people.

In the worst cases, though, some people take it as "ugh, why can't they just provide a yes/no answer to my simple question!?" and the conversation can become increasingly difficult.

If someone's thinking this a lot - like, they think most people are doing this to them to the extent that they wonder why "many people seem to totally lack the capability of understanding simple questions" - it would be wise for them to re-examine their assumptions.

I recently had an experience where a project manager was basically demanding a yes/no answer in what felt to me like a power move.

PM: Are we good to go live on Wednesday? (it's Monday)

Me: Feature X isn't fully ready yet. Data science needs to address a bug that I found 2 weeks ago. If they fix the bug, I'll prepare a release for Wednesday. Alternatively, we can go live without feature X.

PM: Feature X is required. Data science says they'll have the bug fix ready. So are we good to go live Wednesday?

Me: If data science implements the bug fix, I'll release on Wednesday. (I don't trust data science to be ready, but I'm not going to say that)

PM: Okay, so we're good to go live?

Context is very relevant. Yes/no questions often aren't yes/no. I didn't even include the full conversation where I tried to clarify what he means "go live" or whether the customer had signed off. In the end, customers hadn't signed off and he hadn't coordinated with other teams. The release has been put off for at least a month.

I think this is somewhat different than a yes/no informational question. In this case, it wasn't even a yes/no question, it was a yes/yes question, he wanted me to take responsibility.

In that cases my answer is "no". Ends the cycle pretty fast.

PM: Are we good to go live on Wednesday? (it's Monday)

Me: maybe, I'm not sure. ( your answer is incorrect, let the manager probe you further)

> Right now I'm relatively new in my position, and it was a real torture to understand the system, because nobody seems to be able to explain it in a linear way.

This is... not surprising at all? Are you new to industry? Have you only worked at greenfield startups?

Particularly true for products with significant R&D components, btw.

> Ok, where I'm now it seems a PhD can be bought around the corner for 2 cents.

Some advice for hiring people with advanced degrees:

1. The masters degree itself is not a good signal. Especially in CS, MS programs are viewed as pure revenue streams and explicitly treated differently from other programs in terms of rigor and signalling value.

2. The PhD degree itself is not a good signal. For example, the University of Phoenix awards PhDs.

3. Some CS subfields are worse than others in terms of PhD signal:noise. Machine learning is a big abuser -- faculty at lower ranked programs can often get away with using PhD students as super cheap entry-level SWEs/SREs ("graduate student descent"). There are some subfields of CS where a PhD is a better signal. Actually, this can happen at higher-ranked universities as well.

So, what to do?

1. For masters degrees without a thesis component, I'm not really sure. Treat it as a new grad who took some extra coursework.

2. The great thing about a PhD (or Masters with thesis) is that the output is a 100+ page document. You can read usually about 10 pages of that document (intro, conclusion, fist page or so of each chapter) and have an immediate sense for how well the person communicates.

> The masters degree itself is not a good signal. Especially in CS, MS programs are viewed as pure revenue streams and explicitly treated differently from other programs in terms of rigor and signalling value

I discovered this recently. Working in the CS department at a large state school, the masters students are not respected. I have had professors tell me they don't care if they cheat (they mostly do) or share solutions, they are just there to pay their tutition and get their degree. Working directly with some of these students, I have found that they lack understanding of basic computing concepts, even fundamentally how computers work. It's breathtaking. Maybe some schools are exceptions, but I've come to interpret a masters degree in any computer-related subject to only mean that the person had the funds to pay for it.

> but I've come to interpret a masters degree in any computer-related subject to only mean that the person had the funds to pay for it.

Sadly, immigration is a major pull into MS programs, and it's not always the case that the student can actually afford the program... especially if the immigration plan doesn't work out.

Honestly, when I see this kind of story (and I do see it a lot), the confusion is typically more on the side of the person insisting on a yes or no. I had a conversation once with a customer who demanded a yes or no answer to the question of "is your system in-memory". They didn't want to talk about what was in memory - they'd just learned from Oracle marketing material that "in-memory" was faster, so they wanted to make sure we were faster.

To be clear about the yes/no, let me tell you an example from yesterday:

- We are building an embedded system, which has a data interface, which is not working properly (nothing is being received). We have to take care of the emitter, other team the receiver.

- My question: after lunch you are going to see with the oscilloscope of there is activity in the interfaces lines?

- Answer: No need, the registers in the ASIC indicate transmission is ok.

- 2nd question: but maybe there is a malfunction in the ASIC, and still there is no transmission, so we should test.

- Reply: The other team will check if there is reception or no.

- 3rd question: but the other team confirmed there is no reception, even with oscilloscope... could you test?

- Reply: what test do you want me to do?

- Me: measure with oscilloscope

- Reply: what for?

- Me: To confirm the transmission

- Reply: I dont follow...

- Me: here I start to ask, step by step:

    - We have a problem of transmission, right?

    - Yes!

    - Registers in ASIC indicate no problem, right?

    - Yes.

    - The other team reported still there is nothing in the receiver, right?

    - Yes.

    - So it would be useful to physically test with oscilloscope if that is being send, don't you think?

    - Yes, sure!

    - So you are going to do it, later, after lunch?

    - Yes, no problem.

Yes, that guy has a PhD. Is my problem that I'm asking yes/no questions?

You imply that the other PhD is being difficult but I think you're being difficult. In my opinion you should start with an open-ended question "How do we determine if there is a malfunction in the ASIC?".

Unless this is your subordinate and you are convinced of a plan of action. In that case don't ask, just be direct and tell them what you want to test.

In this case is my subordinate. The idea of doing the measurement was discussed with other people, I have 20+ years doing such debugging. I already had asked him to do the measurement. My question started more to be sure he actually is going to do it, because I have experience with not doing what he is supposed to. Not a bad guy, but sometimes seems to just don’t understand.

Btw: at the end the test confirmed the suspicion.

I agree with the parent. When there is confusion like this, switch to open ended:

"OK, we both agree there appears to be a problem with the transmission. How do you propose we investigate?"

From the dialog it appears you were two steps ahead of the person and what he really needed was time to think it through. Asking the open ended question gives him space to think.

Interesting example...

You propose I use an open ended question, where the discussion could easily go sideways, when I clearly stated:

"In this case is my subordinate."

"I already had asked him to do the measurement. My question started more to be sure he actually is going to do it."

I do not see how an open question would help here.

Nice example of communication going wrong here...

Yeah, it really depends on context.

It makes sense to give a subordinate a directive. That he is a subordinate, however, doesn't mean a direct question will lead to effective communication.

I've worked with both types of managers - the ones that ask direct, pointed questions and the ones that ask open ended ones. I think the latter are more effective, but it really depends on the role (you don't want open ended discussions in emergencies).

For me, though, "We have problem X. What are the options for resolving it?" has a better chance at success than "We have a problem X. Can you look into Y?"

It's hard to say without having been there. I've definitely been in your shoes before, where I have to pull teeth to get someone to sit down and actually do what they clearly need to do. But I've also been the PhD guy, saying "yes sure" and agreeing to spend 30 minutes on a task that doesn't make much sense rather than spend 30 minutes arguing about it. I don't have the technical knowledge to speculate on how obvious it should have been that the test you proposed was right.

Ah, this feels like it came out of my mind. It's a perfect example that illustrates some of my own experiences lately. So frustrating...

Some people are truly bad at comminicating.

The other side of this, trying to insist on yes/no answers to questions that are not yes/no questions is also a bit of a recipe for disaster.

> EDIT: I see some answers referring to learning disorders, disabilities, anxiety, not knowing the issue at hand. I'm talking about people which do know the topic

Some learning disorders do exhibit really good math and logic skills but poor conversational skills. Or just requiring a lot of time to put thoughts together and being really bad at on the spot real time conversation. Casual conversation and being academically talented are really pretty distinct skills that dont neccesarily come together.

I would go further and say that "yes" and "no" are never the only acceptable answers to most questions unless you are able to prove the answer is deterministic.

"will you have the project complete by Friday?" -> you may be able to state "no," but there are certainly caveats to any "yes" answer.

"will you try to have the project complete by Friday?" - in this case, "yes" is most likely an acceptable answer, but you still probably want to pull in additional context, e.g. "but I am prioritizing x, y, and z."

Good, correct conversation is rarely binary.

The problem for me for cases like your example is, that I need an answer that I can work with. If the answer to that question doesn't start or end with "yes" or "no", I'm then left with having to read between the lines of whatever rambling answer I received to determine, whether they're more likely to be finished by Friday or not.

"Well I started with this module and Bob is still doing stuff, but it seems like some work still. Ah, also have this meeting tomorrow - btw do you know if Alice is joining? Did we say you prepare the slides or does she do it?" leaves me hanging not knowing whether they'll manage or not and we're off to a side discussion.

"Yes, unless Bob can't get this merged until tomorrow." or "No, this became way bigger than expected. Do you need to communicate this to someone, or is it blocking you and we might be able to split it up to unblock you?" are way better answers. It shows that the person understands the scope of their task, they can estimate roughly the amount of work, but also stay open to prioritize or compromise.

Even "I don't know yet, as I first have to read through this document to get a grasp of the scope. I'll come back to you in the afternoon" is a way better answer that's neither yes or no, but you take the responsibility to find out.

IMHO you can pretty much always provide clear answers, but it requires for you to understand the scope, the shared context and some social intelligence to realize, that the other person probably has a reason for asking and that the questions or anecdote that just came to mind should probably be of lower priority.

I guess there are different types of questions. If i needed someone's permission to do x and they didnt answer yes/no, thar would indeed be annoying.

I think what i was reacting to was more the types of questions like "can the site scale to 50,000 users? Yes or no" where the real answer is, well it depends on how active they are, what they do on the site, are they are logging in at 9am monday, or a million different factors and there is no reasonable yes or no answer.

Define simple; it is often the case that something seemingly simple is actually quite complicated.

It is often good to provide additional context to identify common ground and from there guide the discussion.

A system that can be described in a linear and continuous fashion without drilling down is either too simple, or too broadly described, neither of which is particularly useful when complexity is high.