Although Python’s popularity continues to soar, recent trainees and junior developers usually need more than a cursory understanding of the language to land their first job. “Managers are looking for people who have thought critically about their tools, instead of accepting them blindly just because they are in style,” said Mark Lutz, a Florida-based trainer and author of several books on Python. Click here to find Python-programming jobs. Answering the “how” questions is always important during an interview, Lutz explained, but answering the “why” questions suggests a dedication to improve and grow—not just earn a paycheck. With that in mind, Lutz provided some of the common replies to interview questions for Python newbies, and the answers that he’d rather hear instead. How do Python 2.x and 3.x differ, and why should you care?

• What Most People Say: “I don’t really understand the differences between the two versions, but I noticed that the print statement becomes a built-in function in 3.x.”
• What You Should Say: “The more significant 3.x changes include: differing and more pervasive Unicode support; mandatory usage of new-style classes; deeper integration of iterables and functional programming tools; and change, replacement, and deletion of many built-in tools (not just print). Of these, the 3.x Unicode model may have the largest impact, as it touches on strings, files, and a host of application-level interfaces in the standard library and third party domains. The new-style class model elevates topics such as the MRO, descriptors, and metaclasses from optional topics to required reading. And the more widespread role of iterables demands more careful use of tools like zip() results and dictionary key lists, for display, multiple traversals and object-like lists.”
• Why You Should Say It: The Python world still uses both lines, and the vast body of existing 2.x code will probably be a permanent part of the Python ecosystem. Therefore, you need to understand both versions to maintain or port old code, or write new code that works on either line agnostically. While the first answer is correct, it reflects a superficial understanding of a major pragmatic dilemma Python programmers face today.

These three statements run in series: A=[], B=A, A +=[1]. Does the third statement change B?

• What Most People Say: “No, only A changes. Wait, I think B changes because it prints as [1] after the last statement runs, not [].”
• What You Should Say: “B doesn’t change and continues to reference the same object it did after the second statement. Rather, the object that B (and A) reference differs at the end because it has been changed in-place through variable A.”
• Why You Should Say It: The better answer draws a distinction between variables that reference objects and objects like lists, which is a central concept in Python. In larger programs, shared objects are often deliberately changed in-place in potentially far-flung bits of code, to update long-lived state. If you don’t understand this model, it can lead to fairly painful debugging sessions when it occurs unexpectedly. If you do, it shows deeper Python knowledge.

What’s the point of using classes and OOP in Python?

• What Most People Say: “Because of polymorphism?”
• What You Should Say: “OOP and classes become indispensable as programs grow larger, primarily because they let you use and customize existing code, which reduces development time. OOP also provides code structure and avoids the pitfalls of global data that vex much function-based code. However, developers need to consider other issues. For instance, it’s OK to code functions, modules, and even top-level script code as long as you don’t expect them to be flexible enough to be reused in other programs. Top-level script code is always a one-program effort, because it runs immediately and has no container object. Functions can be imported and reused to some extent, but they don’t directly support growth by extension and must rely on arguments and single-copy global data for recording state information.”
• Why You Should Say It: Since OOP and classes represent a fundamental design choice, it’s crucial to understand when they should and shouldn’t be used. Classes provide a hierarchy that fosters extension in ways that functions and other tools cannot. An interviewee who doesn’t express this probably hasn’t moved beyond the trivial programs phase in the learning cycle, Lutz said.

What do you think about Python’s “batteries included” paradigm?

• What Most People Say: “I like it. Why spend time reinventing the wheel when wheels are available for free?”
• What You Should Say: “Batteries included is great, under certain circumstances. The quality of third-party code can be iffy and the resulting product may not support your company’s needs. In truth, cut-and-paste code could become your code base’s weakest link. You need to carefully review the code and consider the consequences to make prudent case by case decisions.”
• Why You Should Say It: Blindly parroting the mantra that code reuse always beats writing new code could be a sign of a shallow perspective, which may produce code-maintenance nightmares down the road.

Why would you use the super() call and why would you not?

• What Most People Say: “super() is awesome, because it works just like it does in Java; you should use it whenever you can, instead of calling methods by class name.”
• What You Should Say: “super() has two primary roles: In single-inheritance class trees, super() can indeed be used to invoke a method in a superclass generically. This role is essentially as it is in Java, at least for trees that will never grow to include multiple inheritance. In multiple-inheritance class trees, super() can also be used for cooperative method-call dispatch, which routes a method call to each class just once in conforming trees. This role is more unique to Python, and works by always selecting a next class on the MRO following the caller that has the requested attribute. Unfortunately, super()’s second role may have a massive downside: Its automatic method routing makes for a wildly implicit code invocation model, one that can obscure a program’s meaning, create deep class coupling, hinder customization and complicate debugging.”
• Why You Should Say It: An interviewee who describes any of super()’s downsides gets Lutz’s vote. On the other hand, a person who only lauds the Java-like role in single-inheritance trees would strike him as someone who will probably code Java in Python. Worse, the candidate may pepper a code base with complex and obscure tools in some misguided effort to prove personal prowess instead of practicing sound software engineering.

Have you ever written a perfect program?

• What Most People Say: “Yes! And I’ll write even more if I’m hired!”
• What You Should Say: “Of course not! Even though I strive for perfection, I don’t think anyone has ever written perfect software. That’s why I test repeatedly.”
• Why You Should Say It: Perfection doesn’t happen in code and responding otherwise might suggest a towering ego that could sink an entire project.