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”.
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)...
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.
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.
A currency we have in fluctuating quantities
It could be anywhere from a mildly less effective team to a highly toxic work environment. That could matter in a real way.
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.
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.
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 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.
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.
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.
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";
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
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
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.
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.
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.