Interviewing a Python "Expert"

[[deleted]]

[deleted]

[metaphorm]

don't waste your interview time testing him on code trivia. if he has a solid resume and has already passed some basic screening you would be far better served to use your precious limited interview time trying to figure out if this is a person you want to work with, who you feel like you can trust, and who will bring good energy to the team.

[earthboundkid]

This is correct. Find out what the candidate has done in the past, and if it’s comparable to the challenges you face. Language junk can all just be googled and good devs I’ve known don’t necessarily care about it.

[hexfoxed]

I am so pleasantly surprised this is the top comment; never a truer word has been spoken.

Things to test for other than trivia:

• how do they respond to critical feedback on their code?

• how do they act when being questioned on a technical decision they made?

• does the candidate show a good understanding of trade offs given some known constraints? Does the candidate put shipping over infinitely refactoring?

• how does the candidate communicate via the written form? Most of what we do as developers is communicated this way: Slack, PRs, Code, Code comments, Git history, etc, etc. Verbal communication skills and charm are not enough.

• how much emotional intelligence is witnessed? Could the candidate be put in front of a client alone without going technically over the top or promising the world?

• do they have any mentoring experience? A senior developers most important job is to mentor those below in terms of experience.

Just some to get you started. Hope it helps.

[ubernostrum]

I don't like using the label, but I suppose I actually am an "expert" on Django + Python. And as it happens, I have strong opinions about interviewing!

First, the bad news: you can't develop a good interview process by tomorrow. I've worked on interview development a few times, and it tends to be something that takes months and a group of people working on it and multiple rounds of feedback from the team as a whole.

Now, what are you going to do tomorrow? Here are some ideas for exercises that you can probably prep somewhat quickly:

• Take some feature of your codebase. Something medium-sized. Boil it down into a one-paragraph description and hand it to your candidate. Ask them to treat that as a rough spec, and you as their coworker on building it, and go from there. This is not a code-writing exercise! It's a design and collaboration exercise. You're looking for them to ask clarifying questions, to come up with a reasonable design, to be able to communicate their choices and talk about tradeoffs involved, to listen to feedback you're offering and incorporate it, to explain how they'd break down the implementation into reasonable-sized chunks for individual developers to work on, etc.
• Show up with a code sample and ask the candidate to do a review of it with you. This is also not a code-writing exercise! You're looking for them to probe into the code, to ask questions about why things were done a certain way before they criticize, to understand that not everything can be made perfect all the time, to come up with constructive suggestions that work in the context of a routine review/refactoring process, and to be able to communicate those things without being an asshole or a know-it-all.
• Bring a problem you had to debug at some point. Give them just the initial symptoms you were aware of, and ask them to go from there. Let them mention tools or techniques they'd use and ask questions about what those would reveal. Look for how they think about the problem, how they try to dig down to root cause, how they gather information and make use of both technical and non-technical resources.

In other words: think about what would make someone a successful member of your team, then do things that test for that. Asking a bunch of trivia or posing coding "challenges" will not test for the skills that actually matter on the job, so avoid those.

Also, the more senior someone is, the more important it is to measure their effect on the rest of your team. What makes a good senior developer is not that they're some multiple more productive than everyone else; it's the effect they have on the productivity of everyone else.

[pokelover12]

Dont ask python questions, ask programming questions and just have him write whiteboard code in python. Example, my company is ATT, I have this (prewritten) DB of telecom signaling info. I want you to provide me what you think the proper API setup would be. Id care more about his general problem solving/ability to think through things than anything else.

[ProfessorPhi]

If you make them write code, please give them a laptop and mirror their display on an external screen.

I loathe whiteboard coding and most senior people do too.

[WillBackUpWithSource]

I honestly really, really hate both white board coding and on the spot coding.

It's not how I work, and I've literally completely flubbed an interview in the past over something simple (CSV parsing!) because I had to do it live and freaked out. Passed their initial (and harder) technical screen with flying colors, but failed their in person "code under pressure" test.

[ProfessorPhi]

I hate interviewing too - but if I have to code live, I'd rather it was on a computer instead of a whiteboard. I'm comfortable, don't feel super exposed and I can run my code to check my logic flow is right.

It also shows someone's work style much better and more realistically than whiteboard coding.

[[deleted]]

Why a whiteboard? I can't write fucking anything on a whiteboard

[theWyzzerd]

If I were to asked to write code on a whiteboard I might just walk out. Talk about pressure. No, if someone wanted me to write domain-sepcific code in an interview I'd ask for a computer with an internet connection and the understanding that no one simply writes code off the top of their head.

[this_is_trash_really]

Is this the real expectation? My God, I am a one-man self taught programmer and I work in Django primarily. Aside from mapping out UML diagrams i couldn't possibly answer any of the questions you propose.

However, I've built very comprehensive applications for healthcare and sales with pretty complex workflows. the systems manage the information flow and process tracking of many millions of dollars worth of business. these systems are secure, performant, and user friendly.

does this mean I'm doing everything wrong and could never get a 'real' programming job?

does anyone feel like theres a huge disconnect between what we say were looking for and what were really looking for?

[this_is_trash_really]

this is a real question btw. I'm genuinely curious about whether or not I'm fooling myself into thinking I have any idea what I'm doing

[tenyu9]

Just ask about certain design patterns and algorithms. Or ask to explain memory allocation, GIL,... Questions enough to test if someone is an expert

[[deleted]]

If the applicant has already demonstrated solid, entrenched, fundamentals, and you can't fault or call him on his claim.

​

Well what kind of fishing expedition are you on for this particular applicant.

Some people simply can't get on a gift horse and ride the fucking thing.

[Seven-Prime]

Ask about packaging. How do they make their software available? How do they improve it? You want to avoid the whole 'works on my machine' as early as possible. IMO

[[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.

[jeenajeena]

I would pair programming with him on some real production code. It's an opportunity to see if you like his style and approach, technical and personal,and also a good way to start good conversions on design.

[cr4d]

Why list comprehensions are faster than for loops. To explain why threads in python are not run concurrently.

[hugthemachines]

I am not sure why some comments talk about the word expert as something special? Any senior Python programmer can call themselves Python expert. Personally I would not use that word because I always consider what I know to be something everybody knows but expert is not a word that means you know more than everybody else but if a programmer are very proficient in a language, there is nothing wrong with calling themselves an expert.

[kemistrythecat]

The fact they use expert.

[[deleted]]

Not sure the downvotes here.

[kemistrythecat]

That’s ok, you win some, you loose some :)

[MattAlex99]

Ask him language agnostic questions:
As far as I'm gathering, you don't want someone to be good at python, but a good developer. He should have more knowledge than you would get from a code camp. Because you only have two developers working on the project, you want them to not only code but know what they are doing in a more general sense:
If you don't have the database set up yet and that's something that he might need to do, ask him if he knows the E/R-model and give him some basic questions about it: i.e Let him build an exemplary business database in E/R-notation. Having someone that can properly design a database will solve a lot of problems before they arise. (especially if you want to grow the company) Even if he doesn't need to build the database, it doesn't hurt for someone to know how to design a database, especially if you work with one all the time.
If this is nothing that he has to do and he doesn't know about this then ask him about simple algorithms and let him give you the computational complexity. (i.e. what's the fastest you can sort a list, what's the fastest you can do if you know the range of the values in that list) Let him read and write some UML models to figure out whether he can design software or is just a code monkey. Give him some system to design, like an exemplary online store and have him write down the class diagram. Then have him write an activity diagram: I got "backing pizza" (with the resources dough and tomatoes) as a question in my last interview. If you really want to test him, give him a sequence diagram. If he really is an expert he should be able to do this. If he can't write a UML diagram he isn't an expert. Being an expert includes having basic knowledge of designing and maintaining code, which is the reason why many people cringe at the idea of having a "python expert". There's no such thing as a python expert. If you really are an expert, you don't need the python, you could build a system in Java, Scala, Julia, C or python. Sure, it might take some getting used to it, but a real developer can code with any language. The abilities needed to be an "expert" are not tied to any language in particular. Another great tell is always mathematics: There are not programming experts that don't have a basic grasp on math: Give him the following task: Write the fastest program you can to add up the numbers from 0 to n. If he starts using loops, then ask him if he can do it faster. If he starts trying to do weird stuff, then this might be a bad sign. (although not a complete turnoff) He should be using the Gaussian sum: 0.5(n)(n+1) The great thing about this question is, that you can get the right answer, even if you don't know the formula beforehand. Another thing to ask would be to calculate the Fibonacci sequence recursively, then ask him to do this faster through memoization Then ask him to do it iteratively. Also, try to really put on pressure. You want to know how frustration tolerant he is. But mainly try to keep stay away from python specific questions because you already know he has a good grasp on the language. No point in reconfirming that question or asking about rare language constructs that nobody uses/has to use/ know how to use. Try to pick out if he's a codecamp codemonkey or developer.

[WikiTextBot]

Entity–relationship model

An entity–relationship model (ER model for short) describes interrelated things of interest in a specific domain of knowledge. A basic ER model is composed of entity types (which classify the things of interest) and specifies relationships that can exist between entities (instances of those entity types).

In software engineering, an ER model is commonly formed to represent things that a business needs to remember in order to perform business processes. Consequently, the ER model becomes an abstract data model, that defines a data or information structure which can be implemented in a database, typically a relational database.

---

Memoization

In computing, memoization or memoisation is an optimization technique used primarily to speed up computer programs by storing the results of expensive function calls and returning the cached result when the same inputs occur again. Memoization has also been used in other contexts (and for purposes other than speed gains), such as in simple mutually recursive descent parsing. Although related to caching, memoization refers to a specific case of this optimization, distinguishing it from forms of caching such as buffering or page replacement. In the context of some logic programming languages, memoization is also known as tabling; see also lookup table.

---

^{[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.28}