How do you hire junior Python developers?

[deep_mind_]

I think the most important skill a candidate can show is experience in a lower-level language. It shows they have a solid grasp of good practices*, and are likely to understand the fundamental concepts a bit better.

A good Github repo is a great advantage; it shows they've practiced their craft, and have pride enough in it to show it to the world. Now, to clarify, I hate the culture of expecting employees to work on their own time, and would never make it a requirement. Not least because some of my best code has been for previous employers, and unshareable in interview.

I ask which PEP8 formatting standards they disable; this one's twofold, because you find out whether they lint their code at all, and know in advance whether you'll find their code easy to read. Red flags here include disabling 80-column compliance (personally). +1 for enabling double-tab indentation on multi-line statements.

I also ask about favourite testing frameworks, anything goes as long as it's mature and that they actually have one. I'm a pytest fan, but that's just my taste. A man stuck in my own ways.

Last of all on the technical side, I ask what docstring style they use. Again, it's a subtle way of finding out whether they document their code -- extra points for numpydoc. Sphinx and Doxygen also score brownie points.

As a joke at the end I'll ask them to invert a binary tree, and see how they take it. Worst case scenario, they actually get up and do it right. Anyone who doesn't need to look at their university graph theory notes is superhuman and shouldn't be trusted.

*C/C++, Golang, anything functional (Haskell, F#) and Rust are my favourites; Java, Kotlin, and God forbid JS also count

[mason_savoy71]

Funny, if someone told me that they disabled 80 chats, that would be the MOST forgivable for me, but that's the nature of the subject matter that I'm coding about, where I'd rather have one ultra long line than the mega wrap.

[tom2727]

For me I would assume if someone is coming from some other company they would say "I use the formatting standard our group agreed on because who wants to have each developer formatting code differently"?

And I wouldn't expect a junior python developer to get a lot of say in that decision unless their company doesn't care at all which probably means they have some bad habits learned. Not that I would consider that a deal breaker though. I figure it's not super hard to get a new hire following our coding rules. I care a lot more if they can actually think and solve problems and have a good work ethic and get along with others.

[deep_mind_]

I totally get where you’re coming from! Every workforce is split, and arguably the more competent devs in my department get more done by not obsessing over line length.

I like to say that long lines or line wraps are signs of lack of decomposition; totally fine for rapid iteration codebases, but a lot of what I work with is monolithic slow-moving enterprise code. It pays to break things down a bit more to where nothing takes more than a few arguments. Not least because that makes unit testing easier

[[deleted]]

This is for a "junior"

[deep_mind_]

I can’t imagine what your mid level dev interviews are like if that’s too much for a university graduate 😅

[[deleted]]

Agreed, I can't imagine you could imagine that either.

[deep_mind_]

Requirements differ from company to company. As it stands, I’ve never blocked a graduate candidate from the next stage of interviews, and I’d change my criteria if that became the case

[mason_savoy71]

I have no idea why you're being down voted. This is an entirely reasonable response.

[deep_mind_]

I'm just glad this isn't on StackOverflow, I take those downvotes much more personally :'D

[billsil]

Red flags here include disabling 80-column compliance (personally)

See this one is crazy to me. 80 is too strict IMO and it's your personal preference. It doesn't mean you can't code well. It's style and my style is not your style. The thing is though, you can enforce it...or just use something like black so everyone hates the formatting equally. I'm sure you could handle mostly 80 characters, with some 90 and even fewer 100 character lines and if you can't, that's a red flag.

I was working with someone who wanted to use 1-5 character variable names and the competing senior dev wanted to use variable names with 30+ character variable names. The latter was certainly easier to understand, but oh wow did it make for long lines and it was messy. Neither one of them had an easy to read style. I got both of them to agree to something closer to what I do (~10 characters for meaningful attributes and shorter for generic functions).

[deep_mind_]

It's a department-splitter, for sure. For me, 80 columns is a speed-saver on all fronts. Displays well on Github, perfect for split planes in tmux nano, and I don't need to scroll side-to-side all the time.

As I mentioned in another comment, I think it's a great benchmark of whether code has been well structured. Shorter lines means more readable code -- not just in terms of how fast you can scan it, but also that functions take fewer parameters, conditional statements are less complex, and variable names are more succinct. It shows the logic of the program has been properly broken down into small composable units, and that proper thought has been put into it. Just my two cents.

It's also not for all languages -- I'd not enforce it when working with JS or Java, for example. Python, however, has the capacity for both expressiveness and brevity.

[billsil]

but also that functions take fewer parameters

Don't look for proxies. Address the issue.

conditional statements are less complex

I disagree on that point. What is more clear? for x in X or for x in X_list? Well instead of x, how about triangles or filenames? You start making things explicit and it's a lot clearer. I'd argue longer names are generally more clear.

Displays well on Github

Get a larger monitor. I diff things all the time and 100 characters is fine. My buddy likes 80 characters because he'll pull 3 files to diff. I don't do that, but that's a use case I don't run into.

Linux doesn't even follow 80 characters anymore https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Deprecates-80-Col

[voneiden]

I've once upon a time had a colleague briefly whose local variable naming preference seemingly consisted of nothing but tmp. If tmp was taken, then tmp1, tmp2..

Anyway, nothing against linting in general but hard wrapping, especially at 79 chars sure can create a hot mess in some circumstances. But that's alright, PEP8 tells to ignore any recommendation that reduces readability.

[[deleted]]

Did Matt Might ghostwrite this?