[my_usernam3]

I find it hypocritical that developers preach "languages don't matter, a good engineer is a good engineer", while also being very specific to work environments. Personally, I want the environment thats most similar to my coworkers to create the least amount of friction during on-boarding and documentation based learning.

Don't get me wrong, there are bad dev experiences that can be had. However, from my experience its definitely not mac vs linux vs pc, but rather intricacies that are unlikely to be able to be explained during the recruitment process. And if they can, why would they? It's not like applicants are being super truthful on their resumes.

[DoofusOfDeath]

It never even occured to me to lie on my resume. Surely I can't be the only one.

[DrScump]

Same here.

One problem with building upon a framework of falsehoods is that to be a consistently effective liar, you have to have a fantastic memory to keep your falsehoods referentially consistent.

When I was on the proverbial other side of the table helping to evaluate candidates, I became flabbergasted with the frequent false skills claims of candidates, especially those sent by job shops.

To me, it would be exhausting to be phony. I'd rather save that mental bandwidth for stuff I can feel good about doing.

[hrktb]

People can be very good at constructing “facts” that are not correct but desirable to them, and not completely devoid of anchoring.

Like that time they were at a book signing event, asked the author for a two-shot, got a smile for a last joke thrown before leaving for the next in line, and now proudly declare themselves “good friends” with that author.

[hrktb]

It’s seldom straight lying and more often omission of critical facts or misrepresentation of their roles on projects. Which sadly is the common advice given to people writing resumes, and it becomes a prisonner’s dilemma.

I assisted at whole interviews where “tech leads’ craftily avoid recognizing they code at most half an hour a day.

Or a dev listing super hard stuff on their resume but never mentioning until thoroughly asked that they pair programmed all of these.

[411111111111111]

Why is pair programming an issue here?

Personally I find pair programming hard stuff way better, because your constantly talking about the challenge a find issues earlier than when you just implement your initial solution.

I never thought that is somehow bad, but I guess people have different worldviews

[hrktb]

It is not bad by any mean. It is essential information that should not be set aside though.

It’s like co-authoring a book, that’s fine, but don’t just say “I wrote a book about xxxx”, be upfront about cowriting it.

[koheripbal]

My broad guess is that 50% of resumes have lies throughout. typically you can smell it during an interview, but on occasion the interviewers that are available aren't themselves technical and people slide through.

[Viliam1234]

Maybe those talking about how languages don't matter are the bad devs, whose ~0 experience in one language is equivalent to ~0 experience in any other language they wrote "hello world" with.

Once I had an interview with a guy who claimed to be fluent in several languages, so as a warm-up question I asked: "tell me any difference between Java and PHP", choosing two languages he claimed to have most experience with. After five minutes of silence, I gave him a fizz-buzz-like test, just to be sure I am not mistaking something else for utter lack of programming knowledge; and he failed at that, too. But until the technical part of the interview, he made a really good impression; good fashion sense, great verbal skills, interesting CV. I think this guy would easily agree with any manager that the importance of a specific programming language is overrated.

Ironically, a similar attitude might also come from the opposite side of the expertise spectrum, where the person would roughly mean "PHP is Turing-complete, Java is Turing-complete, Haskell is Turing-complete, Lisp is Turing-complete; what you can do in one of them, you can do in any of them". Like, sure, given enough time and an infinite Turing-machine tape, of course you can. But if someone has dozen years of experience using language X -- not just the language itself, but the entire ecosystem, like knowing the best practices, good libraries, good build tools, et cetera -- how much time would it take them to acquire equivalent knowledge of language Y and its ecosystem? Especially considering that the typical employer will spend $0 for training and requires full productivity from Day 1.

> It's not like applicants are being super truthful on their resumes.

Relevant: https://www.joelonsoftware.com/2005/01/27/news-58/ Horrible developers are overrepresented at job interviews, because the decent ones usually get the job and the horrible ones have to try again, and again, and again.

If you invite only those with good resumes (makes sense, why would you invite those with bad ones?), you mostly get an intersection between people who suck at programming and have great resumes. That means: liars.

[HeyLaughingBoy]

At my last job, we weren't allowed to interview anyone until we had either been trained in interviewing, or were doing the interview with someone who was trained.

When I took the training class, I assumed it was all about not asking questions we could be sued for, but that probably took up about 5 minutes of the class. Instead, the instructor created exactly the scenario you described. Someone who sounded really, really great and who you'd like to work with, until you thought about what you heard and realized he hadn't told you anything at all.

Good con artists are really good. Even if the average interviewee isn't trying to pull a con, digging into their real experience isn't something we're all good at. Training helps.