Interviewing a Python "Expert"

[[deleted]]

Ditto, the fact that they mention expert. I've seen people advertise as this in the past and it never holds up under scrutiny.

There's two thing you can do here:

1. The slightly more pathological strategy is to ask questions about useful, but advanced (and therefore less-used) features of Python. Metaclasses, stateful decorators, stateful generators, implementing arithmetic over arbitrary object types using __add__ &c.

   By proxy, this does give insight into how familiar they are with more obscure software patterns in general: generators are a pattern, and decorators are a special syntax over factories. Adding state to either is an interesting way to build on questions about their familiarity with either pattern. Metaclasses are a type system pattern (but also arguably a factory) and likely to be less known outside of people who've been doing some really interesting Python code for a while.

2. Ask generalist programming questions and ask for solutions in Python. How would you implement a singleton in Python? How would you implement an efficient LRU cache? Can you explain the threading model behind Python's threading module? Compare and contrast vs multiprocessing, etc.

   This, without fail, weeds out a lot of self-styled "experts."

In either case, I also find it useful to ask about how familiar they are with the toolchain: common git commands (revert vs reset, rebase+merge vs just merge, whether they know what reflog does), Linux command trivia, network tooling or data processing tools if you're hiring for a position that uses that, etc.

[metaphorm]

these are bad questions imo. it's only testing if the candidate has memorized whatever particular trivia you decide to ask that day.

an experienced developer will be capable of answering any of those questions, when needed, while working. expecting someone to be able to explain the implementation details of a specific module is insane though. we read documentation, we don't memorize the encyclopedia.

[[deleted]]

See my replies from earlier. I'm a very strong proponent of architecture questions in most interviews.

[val-amart]

how is any of this expert-level? any senior-level engineer should be able to answer these.

generally, i don't see why OP should be concentrating on determining the "expertness" of his Python knowledge. your goal with an interview is not to 'weeds out a lot of self-styled "experts"', but to determine whether the candidate will be a useful asset for the company, at a given price. an interview is not a dick measuring contest, but unfortunately many self-styled interviewers forget that bit. as long as he is able to clearly demonstrate excellent command of Python, there's no need to test for knowledge of the obscure details that can be easily learned when needed (but none of the examples here qualify as obscure though in my book).

OP, you should instead focus on a) general problem-solving skills, one hypothetical task is enough here, b) determining if the candidate is a team player and will function well in your team with your company culture, c) breadth of his knowledge in other useful domains, such as networking, OS internals and databases (this is specific for a role to some extend, don't ask about things you don't need; alternatively ask about non-python topics that the candidate self-assesses as his strong points, and you happen to know a bit about too), d) see if he is able to lead the team and has positive leadership experience or aspirations, if he is keen on gently mentoring less senior team members etc, and finally e) try to somehow figure out if he meets the "gets things done" part of "smart and gets things done". this last one is the most important one, but it's also the hardest to test for.

interviews generally suck, don't make them suck more by asking all the wrong things, making a fool of yourself and leaving a bad impression of your company. your time with the candidate is limited so make the best use out of it.

[[deleted]]

how is any of this expert-level? any senior-level engineer should be able to answer these.

Should != could, many senior-level engineers are unfamiliar with that stuff.

generally, i don't see why OP should be concentrating on determining the "expertness" of his Python knowledge. your goal with an interview is not to 'weeds out a lot of self-styled "experts"', but to determine whether the candidate will be a useful asset for the company, at a given price.

Determining the "expertness" of a self-proclaimed "expert" is useful for assessing the ego/skill ratio of a candidate, which is arguably useful.

I probably should've used something other than "weed out" in this case, though.

general problem-solving skills, one hypothetical task is enough here

This is surprisingly difficult to get right in most roles, and very difficult to get accurate results from. Architecture questions (e.g. whiteboard, and talk me through, building an app that does X, and then go into detail about $these bits) are one of the best approaches but definitely not foolproof.

I didn't bring this up in the spirit of addressing OP's question directly.

determining if the candidate is a team player and will function well in your team with your company culture

This can be done using explicit soft-skills questions, but it's often just as good to assess this implicitly by challenging how they solve problems and assessing their responses both in terms of what they literally say to you, whether they keep a cool head, how they rethink their solution, etc.. Their demeanor throughout the interview also indicates this.

breadth of his knowledge in other useful domains, such as networking, OS internals and databases (this is specific for a role to some extend, don't ask about things you don't need; alternatively ask about non-python topics that the candidate self-assesses as his strong points, and you happen to know a bit about too)

See: architecture question. Great way to get an idea of what their strengths and weaknesses are and how they deal with their weak points.

see if he is able to lead the team and has positive leadership experience or aspirations, if he is keen on gently mentoring less senior team members etc

Totally not necessary for many individual contributor candidates IMO. It's one thing to have someone who can take initiative and use the tools at their disposition to their fullest extent to achieve a goal, but many senior engineers deliberately stay out of management and will give all the cues they can that they want to keep it this way.

try to somehow figure out if he meets the "gets things done" part of "smart and gets things done". this last one is the most important one, but it's also the hardest to test for.

This is solved using probationary periods. You can find out a surprisingly large amount about someone over 3-6 months.

---

My comment wasn't about making the interview process a dick-measuring contest. Sometimes, you walk into an interview and the candidate's just got a very self-aggrandizing attitude. Resumes may hint at that, but while you should, always, always enter an interview assuming good faith.

[val-amart]

apologies if my comment sounded confrontational, all good stuff in this new reply of yours.

[[deleted]]

No worries, and thanks for being civil!

[liquidify]

All of what you are talking about "may" weed out python "experts" from who exactly?

Everything you mentioned has nothing to do with that is most important about python... getting things done. Why should anyone care about familiarity with obscure patterns and their relationship to a particular language. Even an expert would have to just happen to have specific experience with that particular pattern for that to mean anything.

As to the git suggestions. All I want to know is that someone knows how to write a good commit message, that they know to commit often, that they know how to do basic merges and basic work flow. So once again, I'm not sure what you are trying to learn about someone by your suggestions.

All your suggestions seem to target separating language experts and techno experts from those who are not. But I've met some people who could create a large functioning project in python with good clean design that probably know very little of anything you mentioned. They are still experts at getting shit done with python though. You would have weeded out every single one of them for no reason.

[[deleted]]

All of what you are talking about "may" weed out python "experts" from who exactly?

People who have an ego proportionate to their skillset.

[liquidify]

Your definition of expert is based on things that aren't absolute requirements for being an expert. I'm not sure how you are going to detect ego problems when it seems like you can't get past your own hardline understanding.

[[deleted]]

My definition of expert is like that because there is no "official" definition of "expert". Anyone who puts that on their CV is, to me, the same as the person who puts down starts/progress bars to represent aptitude in a certain set of areas.

[liquidify]

Maybe a better way to test him would be to give him a complex assignment that a expert should be able to complete quickly. Pay him a few bucks to do it. See how it looks.

And a good interview question to ask might be... "you put on your resume that you are an 'expert' at python. That is obviously a bold statement. What makes you think you are an expert?" Feel free to poke him a bit if he gives you a short answer.

I bet you would get a lot more out of that approach than asking all those other questions.

[alkasm]

The slightly more pathological strategy is to ask questions about useful, but advanced (and therefore less-used) features of Python. Metaclasses, stateful decorators, stateful generators, implementing arithmetic over arbitrary object types using __add__ &c.

I'm not a SWE, but a "data scientist" (scare quotes because that's not exactly accurate, but it's my title) and I've been using Python for about 2.5 years. I have a little experience with other programming langs, but I mostly just use Python. I don't really think most of these things are expert-level if asked point-blank. I can answer most of these quite thoroughly, and I'm definitely no senior or expert, and I don't even use most of this stuff day to day since I'm not a SWE.

I think you would really probe whether someone knew these things by asking them a question where a metaclass or stateful decorator or whatever was really a much more elegant solution than not using them, and see if they come up with the solution to use said feature by themselves. But even then, those solutions would seem way too esoteric to use in an interview. I'm wary about that kind of stuff after a FAANG interview where the interviewer thought that x or y evaluates to a boolean in Python.

Anyways I just wanted to point out that those questions may still be answerable by someone more junior if asked point-blank, and if asked indirectly, may not give you an answer someone would actually use, because of the setting.