For example, some of the Middle questions seem to me more things a Junior should be asked, and vice versa.
Specifically, it asks about modulus operator in Middle but expects a Junior to identify the key features of Python.
I would seriously expect most beginners to have some idea about modulus, but next to no idea about key features.
At any rate, I very much prefer a short list of very open ended or very focused questions with lots of room to grow.
Like 3 to 5 questions should be able to fill an hour if they are good questions by my metrics.
For general questions, I like things like "What are the key features of the language?" but I phrase them as "What are your favorite parts of the language? Least favorite parts?"
Those answers are often very telling -- often Juniors will have very shallow answers or none at all for "least favorite".
For specific questions I like things like "reverse a string". Not so difficult that it's a brain teaser, but plenty of room for diving into different approaches and discussing idioms of the language.
Again, these answers are very telling -- often Juniors will only be able to write one very simple version, but a Senior can write several and talk about the trade-offs.
As someone who began learning with Python, I knew many key features before learning modulus, and I don’t think I have even used modulus in a project yet.
>For general questions, I like things like "What are the key features of the language?" but I phrase them as "What are your favorite parts of the language? Least favorite parts?"
And, picking up where I just left off, this change in phrasing would have made a world of difference at the time haha.
That is why I do not ask any language specific questions in my interview process. Good engineers can answer all of these questions with an internet connection and a few mins of googling.
I've found tests designed to depict everyday work to be the most reliable indicator's of a candidate's skill.
(I find funny the "love for metaclasses" that people consider as "advanced Python" - it has its use cases, but it is a bit restricted. Also DO NOT USE ABC - it's one of those "let's take this Java thing and try to fit it" but it manages to be an even weirder transplant than logging)
> Q: Place the following functions below in order of their efficiency.
This is the test where a good amount of candidates will do well on the coding part but will completely miss the math considerations. Performance will vary a lot depending on the size and distribution of numbers (and none of them consider a trivial optimization that's possible)
I've seen it enough that I almost consider it a rite of passage for intermediate developers to "discover" an advanced feature like metaclasses and then use them inappropriately to prove their chops, creating an almighty mess in the process.
I get ABC, and can theoretically imagine it being useful for somebody somewhere, but cannot honestly imagine where that is and that it would not also be overkill. And you can usually just do the same thing some other way.
My question is: Why is it good in Java?
The most dangerous interview question. First you have to establish that the interviewer uses those terms correctly or at least that both of you agree... There's lots of people who know the answer in practice, but never accepted that passing values which are references is not "pass-by-reference".
I've talked to someone who said "this must be just a typo/mistake"... when I pointed out Java is pass by value - in Java spec :-(
Is it me or this sentence makes no sense?
Maybe a practical phrasing would be: "why does running Valgrind on a Python app show that some memory was never freed".
Now, these questions are meant for senior Python developers. How do you define a senior Python developer? I would say: Experience and a deep understanding of the language is what defines a senior Python developer.
But honestly, I think labels like "Python developer" or "Java developer" are not helpful. Good programmers can work with any sane language and they know about principles that work across many languages. Like you (and others in this discussion) I agree that the interviewer should rather look for thinking and engineering skills instead of some language details that are irrelevant in nearly all software projects.
The best code is simple code. Don't try fancy stuff unless it is really needed.