When asking for advice, people often try to sound like they already know everything about the subject. I am guilty of this often. My questions usually contain plenty of unnecessary words and thoughts only intended to make me look good.

Unfortunately, this form of asking for advice can easily backfire. For example, I’d like to share with you a vivid example of how I frustrated a senior engineer by trying to sound like a “know-it-all.”

My blunder

A few months ago, when I first started learning about programming, I came across React Native, a relatively new technology. I heard that React Native would let engineers bypass the existing way of coding mobile apps using Java. Proud of my React Native understanding, I asked a senior engineer at a freeCodeCamp NYC event,

Is it true that the job market is shrinking rapidly for Java engineers? After all, Java code is just an old legacy system whose entire need has been replaced with React Native!

I was wrong. My question had many assumptions that were simply incorrect. I don’t want to go into the details, but it’s enough to say that the need for Java engineers is not going away anytime soon.

My immature way of asking for insight was the direct result of too much pride and overconfidence. I had been stating my personal opinion in the hopes of making myself seem like a really smart guy who has all kinds of brilliant things to say. However, doing so made me look ignorant.

Even worse, I was clearly seeking confirmation. I gave off the impression that I would have gotten annoyed if anyone disagreed with me. It was as though I gave the senior engineer constraints of, “you must agree with me or I will start arguing with you”.

I’m sure the senior engineer felt constrained. If he told me what he really thought about React Native and Java, then he knew I would argue with him. So he was stuck. What he actually said was,

I’m not quite sure it works that way. I’m pretty sure that Java will be popular for quite some time.

Uh oh. He was disagreeing with me. I doubled down. “But React Native will rule all the new apps”, I said and continued with reason after reason. “Blah blah blah…” I must have gone on for quite a bit more.

“Maybe”, said the senior engineer, and he turned away to talk to someone else.

Turning the tables

Weeks later, I researched React Native and discovered how wrong I was.

Months later, I realized how annoying it is when someone asks you for “advice” in a way that tries to confirm their opinion. Another junior engineer tried it on me:

Isn’t using Node for server side JavaScript the best thing to do right now? Doesn’t Node’s explosive popularity mean that people are constantly turning away from old server side languages like Python and Ruby?

“I’m not quite sure it works that way,” I started to say.

“Yeah, but using JavaScript on server side will dominate all the new apps,” he said, and then he kept on giving reason after reason with such confidence.

“Maybe,” I said, cutting him off. I opened up my laptop to do some coding.

I finally realized just how annoying it is when people state their opinions in their questions. They are not seeking knowledge. Rather, they are seeking validation. Not agreeing with their opinion risks getting into an argument. It makes you want to say “maybe” and politely exit the conversation.

How to engage

Here are a few sample incorrect and correct ways of asking for someone’s thoughts on a subject. Notice that the correct versions do not contain any personal opinions.


Since React Native is so awesome, won’t React Native destroy Java’s popularity?


Will React Native have an effect on Java’s popularity?


I’ve been telling everyone that server-side JavaScript is the way to go! Won’t Python soon be fading away?


Is server side JavaScript’s popularity causing less people to code using Python?

In conclusion, when you’re trying to engage a senior developer (or anyone, for that matter), don’t include your own personal opinion. It will make you look like a know-it-all who is both ignorant and argumentative.

Beware, as it’s an easy mistake to make. I still mess it up often and will probably continue to do so for a long time to come.