That’s tough because often I’ve had coworkers who give their thumbs up or thumbs down based on “he had it on his resume and I asked him basic question X and he had no idea, terrible”.

"He used a for loop instead of a list comprehension. he clearly isn't actually a Python programmer" -- actual debrief comments :|

I flunked an interview in a similar manner several years ago.

Hadn't done Java in around half a decade but the company recruiter said that it's not an issue (they contacted me).

Then I got a 30-minute online coding test that I had to do in Java. Took me a while to remember the syntax but finished the required problem in time and without issues/bugs.

In the end I got dinged for not using the Java Arrays library for copying an array (used a manual for loop)...

> In the end I got dinged for not using the Java Arrays library for copying an array (used a manual for loop)...

This doesn't sound like a smart interviewer. They are testing your knowledge of the library ahead of understanding what's going on. I'm pretty sure I've interviewed some people who could pull out Array.Copy for the interview but couldn't tell you that it does pretty much the same as the for loop, and that is much more alarming.

> This doesn't sound like a smart interviewer.

I was slightly upset/angry at first but after thinking about it I came to the same conclusion and ended up being happy that I didn't get to pursue the opportunity any further.

If someone claims to be an experienced python developer and fails to write idiomatic python then his claims are clearly contrasting with his output. I won't argue if prior experience with a language is relevant or not for a job application, but lying in the CV and misrepresenting the work experience and skills is clearly a negative mark on a candidate.

Personally I wouldn't want to work at a company like that

That’s called privilege

A currency we have in fluctuating quantities

That's fair. But I don't just say that because it strikes me as annoying. That sentiment of "a real Python programmer" speaks to a mentality of in-group superiority, which could mean pettiness when it comes to decision-making, and possibly even toxic, hubris-driven interpersonal dynamics.

It could be anywhere from a mildly less effective team to a highly toxic work environment. That could matter in a real way.

> That sentiment of "a real Python programmer" speaks to a mentality of in-group superiority,

I don't agree with you at all. By the context, the term "a real python programmer" clearly meanys a developer who actually has used Python in the past in a remotely significant way, at least slightly above the level of an intro to Python tutorial. Knowing the syntax is not knowing how to use a language.

It isn't elitist or classist to see red flags in a C++ programmer who fails to use smart pointers or doesn't understand the difference between pass by value and pass by reference. If someone passing himself as an experienced C++ programmer fails to allocate memory with new and just throws mallocs around, the reaction would be the same.

> the term "a real python programmer" clearly meanys a developer who actually has used Python in the past in a remotely significant way

As a "real python programmer" that is trying to manage a conversion from Python 2 to 3, I can confirm that there is no superiority complex. We feel whipped and beaten, forced to convert a code-base that has been deemed "legacy" in exchange for a few nice string manipulation features that we don't really need.

A "real python programmer" in 2020 is an abandoned class.

I use Python's comprehensions a lot (list, tuple/generator, set and dict). I would not ding someone for not using them. They're a tool, but not always the right tool.

Also, complex comprehensions can get out of hand and explicit loops become more legible.

I got dinged at a trading shop using C# for using Linq instead of hand-writing the loops. I wasnt given any constraints, just solve X problems. I also wasnt being paid for the test, so I solved the problems in the most expedient manner for me. I didnt get the job. So it goes...

Edit: I would ding someone claiming to be an experienced Python dev that cant identify/understand a comprehension. I've 16 years of experience with Python, so I know a fair amount (though the Python documentation is eternally open in my browser). I'm also the only person on my team with any real Python experience. We're building out extensive infrastructure in Python, so Ive been doing a lot of patient mentoring.

Everyone knew PEP 20 was feel-good baloney anyways. It just took the Python programmers a bit longer to come around.

> That’s tough because often I’ve had coworkers who give their thumbs up or thumbs down based on “he had it on his resume and I asked him basic question X and he had no idea, terrible”.

I do that sometimes, if it's truly fundamental to the language/technology. For example, if someone lists C and clearly doesn't understand memory allocation/ownership well enough to append to a dynamically-allocated array, I'll say no hire. Likewise if someone lists SQL but can't do a join. Maybe if they were fantastic in some other way I'd let it slide but so far that's never happened...

Just don't put things on your resume if you don't know anything about them. It's not that hard. I get emphasizing something because you want to work with it more, but you should have worked with it _some_ first.

During the coding exercise portion of an interview I let them choose any language they like. The exercise is exceptionally simple and doesn't push the boundaries of their language knowledge at all.

If somebody can't do the exercise in their language of choice I have doubts about their competency in general. That seems different than asking arbitrary questions about specific language constructs.

That's my Men In Black type of indirect interview screen. "In the language you're most comfortable with, implement xyz".

They then proceed to use the language that was listed on the job posting, that they're clearly barely familiar with, to answer the question. Typically incorrectly.

When I was interviewing devs, I rarely asked anyone to whiteboard. Instead, I came in with around a dozen small C++ apps. Id tell the candidate that unless told otherwise, the code compiles and links with default compiler settings (g++).

Id ask them to tell me the output (all of them would print some result). The examples were pretty small, most less than 20 lines, but each exposed understanding of the language. One they told me their output, always had them explain their reasoning and justification.

One of my favorites was:

    if (~false == true)
        cout << "true";
    else
        cout << "false";

This little gem exposes understanding of a few operators, as well a bit of the type system and automatic type conversions. I have had some that didnt even know the bitwise inverse operator.

I may have been a bit of a dock as an interviewer, but my goal was to get the candidate to say "I dont know". Wanted to make sure they wouldnt lie and try and bullshit. When I got the "I don't know", the followup was key: how,if, they would go about finding a solution. Being a dev isnt about knowing/memorizing everything, but effectively using research skills.

For the examples I provided that didnt compile, I always provided the error message(s), and then asked them to correct the program so it would compile.

Edit: formatting

My response would be:

Doesn’t matter what the output is.. fire the person who wrote that code. If that’s what your codebase looks like, good luck finding and keeping people.

Also, yes bitops are nice and everything. But unless you’re creating games, or working on ffmpeg, you have no need for them except in certain fields to combine option for certain libraries

If someone writes a skill on a CV I expect it to be true. Before talking to prospective employees I ask them to submit code that they have worked on in private or professionally and once a guy sent me code from a tutorial that was easily googleable. He didn't get the job!

Lying on the CV is not proper and it's much better to write that you are a quick learner. I've hired people with little relevant experience but with a good brain.

It's like writing that you are fluent in a (human) language when you can barely scrape by with a greeting and goodbye.

In my case (and in my recommendation), it's more like writing that you "know" a (human) language when you can get by with it conversationally in a foreign country, even if you couldn't go off and immediately write a novel in it, unimpeded, without a dictionary.

There are different definitions of "knowing" a language. I'm just arguing that the one that should be used on resumes is one of basic competency, not necessarily high expertise, unless you're specifically applying to be a specialist. That's not lying.

The positions I usually hire for are very specialised indeed, but I guess it's also comes down to cultural differences. In Norway you would usually specify at which level you know human and computer languages and it would be considered quite rude to put something on the CV that you only have a basic knowledge of. It gives off a feeling of "padding the CV" to appear better than it really is.

If someone writes that they know a (human) language without further specification I'd expect them to be able to speak and write it in a professional setting.

You should be able to answer the basic questions, but you shouldn't need years of professional experience with something to feel like you can list it without a "learning " prefix

I don't think I'd endorse this strategy. I've seen a few resumes mention Rust just because it's popular without actually knowing much about the language. If I see something on your resume I expect you to know it.

One of my personal projects was substantial enough (a dozen files or so) to encounter most of its main features, I've just never worked on a team with it, or shipped it in a product, and I know some but not all of the go-to libraries that everyone uses