I am OK with being vulnerable but you can't explain certain things to ignorant recruiters, middle managers or CEOs. You can explain things to them but they will have an idealized uninformed idea in their head and compare what you said that to that. A good example is recruiters demanding 10 years of Solidity when Ethereum was launched in 2015. If you tell them that, they will get butthurt because you contradicted them or showed that they are uninformed about a topic, but if you just claim you have 10 years of experience, they will be happy in their bubble and hire you.
Of course, this is a different ball game when you are discussing with someone who also has programming / technical skills, for example, project managers with programming skills. You can explain certain decisions, troubles, and imperfections to them and they will get it. But someone who has no experience in the field will just make a negative assumption and run with it.
First, you end up working with people that make it past recruiters that require you to lie.
Second, you don't end up practicing the skills of tactfully educating someone that is a gatekeeper. For example, if someone said something like that to me I'd say something like "oh, well, the person who sent you that requirement must have meant cryptocurrency experience since, Solidity hasn't been out that long." No need to make some less technical recruiter feel stupid.
Third, you develop the skin you need when you are really wrong and can't hide it. If you fail and take ownership of it routinely enough it will allow you to accept it better when you have no choice.
My favorite ads like this are the string of Foxconn ads that have come out over the years. All of their ML jobs required N+3 years of experience with PyTorch where N was the age of PyTorch. Etc. Anyone could tell the "silicon valley" thing was a hoax by just reading job ads.
I just looked at their current postings and there's even one that asks for a "Computer Vision Software Engineer" whose job will be "porting 3rd party functions or GPL", which is pretty transparently the result of a game of telephone that start with "'rewrite' FOSS code so we don't have to follow the license terms". (Which in CV probably isn't even going to help because that whole space is extremely patent encumbered... in that space, if you're "porting" code you are almost certainly infringing patents).
The best recruitment spam I’ve ever seen was a 6 month contract in some awful backwater. It required “20 years of Linux experience” and “10 years of Xen development”
This is really interesting and I think a fundamental difference between engineering and law (my profession).
In the legal sphere the incentive is basically to act like everything is perfect at all times. Technically according to the law you can be sued if you had a wheelchair ramp work 364 days a year but be closed on one.
You can be sued for clearing 99pct of the ice from your driveway if someone slips on the 1pct. If you'd cleaned 99 pct of the driveway as a lawyer you would announce: we cleaned the driveway!
The engineer might opine about how she failed to get the last 1pct and why. The lawyer would tell her to be quiet because she risks being sued.
To my mind the engineering model is better. I don't like the legal model. But it is what exists, and I guess this is why we tell engineers to delete their Slack logs every couple of years.
Maybe if you don't leave a paper trail. If you use a written medium to communicate failure, there is a good chance that will be exposed during discovery in a lawsuit, and now the plaintiffs can show that not only was there a problem, but that employees were aware of the problem and did not fix it.
The news article practically writes itself. "Despite repeated claims that all ice had been cleared, internal documents show multiple employees were aware that only 99% had been cleared. These emails show considerable concern about the remaining 1% of ice, but no further action was ever taken by the company to rectify the dangerous situation."
I don’t think this is bad advice, but you can’t do that for everyone, not all the time.
First, make sure that feedback comes in a context of trust. Say it’s a vendor — give it after it’s signed. They’ll likely forget your name seconds after the contract is signed. Still, that’s when you are not trying to get something from them. Because of how they are focused on sales tactic, they’ll be tempted to hear your feedback as disingenuous.
Same: context is everything. Raising it in front of their boss isn’t always the best approach—especially someone as perfectionist for idiosyncratic things as sales middle-managers can be.
It has to be actionable. It has to fit the rhythm of the interaction. The person has to be in a listening mood, not following a script.
That’s why I recommend techniques to open all those doors: humour, especially self-deprecation, can be very instrumental to feel if someone is receptive to constructive feedback.
This advice only works in startups. In large cooperations its career suicide. Unless you really screwed up, then you might attempt to control the narrative fallout this way.
The asking for explanation never serves the gathering of information, never serves actual optimal solution searching. Its always a power move, trying to get people to justify them-selves, to knuckle under. All is a social power gesture, all is a attempt to crawl over the backs of others to some imagined position at the top of the silo.
If you encounter this, a company is lost to technology. Nobody will discuss engineering discussions, as all is "ammunition" for the eternal civil war of all against all, which might be used against you in some ritualized self-criticizing public execution, disguised as a code-review.
If people ask from you to be self-criticizing, its as honest as asking for your weaknesses during a job-interview.
This is entirely contrary to my experience. I’m a very senior person at a company whose name you definitely know, and I am constantly talking about how things I did could have gone better if I had done things differently.
Aspire to have, and work with people who admire, integrity.
Edit: I also talk about my weaknesses during job interviews, and I have never had it keep me from getting the gig.
I've worked at companies you know that 100% fall into both categories. It's all a matter of corporate culture, and there's no rule that corporate culture has to be a certain way (even just for successful companies).
If it's a big company though, accept the corporate culture is always going to be how it is.
If it's not to ones liking, it's easier to find a different employer.
I think it depends on the company you're interviewing at.
If you're interviewing at Amazon, you better have some cases you've prepared where things didn't go according to plan, and where you learned something from that. You had better be willing to stand up and say "I don't know", but you should also quickly follow that with "I will find out and get you the answers within X days".
I recently shared the reasons why reviewers rejected one of my papers with another PhD candidate I work with. He found this feedback useful and it sparked a good discussion about what he wants to emphasize in his current paper.
Even though in a sense we're competing for the same limited publishing space, we get more benefit from cooperation, because these kinds of critical conversations ultimately make us both better at our craft.
It's only partially true. There's a reason people hide their cards in competitive games (like poker or bell curve-fitted tests) – it can put you a higher relative rating.
However, humans are complex and if you have a trust codex like "i am open to sharing openly only with others who respect this codex", it'll benefit the participants – iff the game is non-zero sum and has repeated interactions (such as most careers, especially in creative professions).
Such a meta-game is more fragile (trust can be eroded quickly), but can benefit everyone in an absolute sense. This game theoretical fundamental truth can be found in animals with symbiotic relationships, as well as codified in moral frameworks (eg the Christian golden rule).
Search for "evolution of trust" if you want to see interactively how it plays out, it's fascinating and highly applicable to social behavior and cultures.
Of course, this is a different ball game when you are discussing with someone who also has programming / technical skills, for example, project managers with programming skills. You can explain certain decisions, troubles, and imperfections to them and they will get it. But someone who has no experience in the field will just make a negative assumption and run with it.