The job market for Python programmers has never been brighter. The US Bureau of Labour Statistics estimates that 100 new Python jobs are created each second and, by 2025, there will be more job openings than people who have ever lived. With such a high demand it’s not surprising that many people are looking for jobs, which means lots of people are looking for interviewing questions, and that’s where I come in. I decided to create a list of the best interview questions for both interviewees and interviewers alike. Only the most awesome and rigorous questions will go on this curated list.
So how did I make sure the list is awesome, rigorous, and curated? Here’s how:
Awesome: Awesome is hard to define, more of a “know it when you see it” kind of thing. Fortunately, a lot of other people have already seen it and known it for us: here’s the awesome list of lists of interview questions, which is definitely an awesome source and not, say, a pile of questions like “What does :(){ :|:& };: do on your system?” or “If you were stuck on a desert island with only 5 command-line utilities, which would you choose?” I scrolled down to the Python section and copied the few articles. 100 awesome questions, easy!
Rigorous: This much more difficult than it sounds, and it sounds very difficult! To be rigorous, it must have rigor. The best way to give a question rigor is to create it from a rigorous algorithm.
One such algorithm is the Markov chain, which takes a set of question and mathematically creates new ones. Markov chains have already seen great success in the fields of literature and research papers, so there’s no reason we couldn’t apply it here, too.
I took all of our awesome questions and dropped them in a text generator I wrote two years ago and out came a stream of rigorous, computer-generated questions! Or at least a stream of words, some of which kinda make sense.
Curated: I looked for complete sentences.
Awesome, rigorous, curated questions in the headers and awesome, rigorous, curated answers right below. Let’s get started!
Explain how you reverse a generator?
What an awesome and rigorous question! Your first thought might be “reversed()”, then your second thought might be “but that would consume the generator”, then your third thought would be “what if I copy the entire generator with list() and then use reversed()” and your fourth would be “but what about infinite generators”, and your fifth would be “the question asked for how you would do it not would it finish in finite time.”
As you can see, this question alone can easily generate six hours of interviews, witerboarding, pair programming exercises, and a Hacker News article on your recruiting process.
In python What are the difference between xrange and Flask?
xrange is a function that returns an xrange object, which is a kind of like a range but uses constant memory. Flask is a Python web framework. While they might seem almost identical, there are a few subtle difference:
- xrange is Python 2 only, while Flask is compatible with Python 3.
- You have to import flask to use it, while xrange is a built-in function
- Flask has its own tag on SO but xrange does not
If you receive this question in an interview, don’t feel bad if you can only list a couple of difference. 1–2 difference is considered standard, 3 is good, 4 exceptional, and 5 unheard of.
Write a string rather than list comprehension?
>>> type("💩️") == str=> True>>> type("💩️") == list=> False
Looks good to me!
How is the following code? What is docstring in Python?
>>> What is docstring in Python?File "<stdin>", line 1What is docstring in Python?^SyntaxError: invalid syntax
Looks good to me!
Do functions (or methods) return something even if you come up with pipes that are bindings, i.e., what is dogpile effect?
What makes this question so interesting is that it explicitly asks you to work backwards: The answer to the first part must be equivalent to “dogpile effect” or else we have a logical contradiction. However, we know that functions (or methods) return something, which means that our pipes that are binding must act as a transformation on the “functions (or methods) do”. So the correct answer to this question is collections.defaultdict.
What are the use of an object in python if you create a number?
This seemingly-innocuous question opens up a deep discussion about Python’s typing system. Many languages, such as bash, are monotyped. After all, everything boils down to just 0’s and 1's! Similarly, in Python, you can map the types onto numbers: True is 1, False is 0, 7 is 7, etc.
So, if we create a number, what are the use of an object? Why not just use the number? While they are intrinsically equivalent, objects have one advantage over numbers: they can have methods. For example:
>>> True == 1True>>> assert True.__doc__>>> assert 1.__doc__File "<stdin>", line 1assert 1.__doc__^SyntaxError: invalid syntax
That’s what are the use of an object, even if we create a number: an object has documentation.
Do functions (or methods) return something even if there isn’t a program to write a program to read global variables in python?
This is actually more of a cultural question than a technical one. If there isn’t any program that writes a program that reads global variables, then a trivial application of Karlmugrerv computation shows that some subset of readers aren’t writeable, which means that by lambda-function equivalence any global function can be written but never read.
This raises a philosophical problem: if a function is written in a forest but there’s nobody around to run it, does it still return a value? The debates are complicated but basically boil down into two camps: proceduralists think that function’s return value is only meaningful in the context of passing time, while functionalists believe that functions are timeless, platonic ideals and with equally timeless return values.
If you get this question, use it as a springboard to learn the philosophical culture of the company. While both are valid, I personally think functionalists are more progressive. After all, they have a separation of Church and state.
Ha ha, get it? Moving on.
Why would you reverse a class or tuple method?
Why indeed! According to Barroso and Hölzle, 10% of the total cost of running a datacenter just goes into cooling the processors! While we’re making great strides in power-efficient computing, the third law of thermodynamics tells us that any irreversible process will increase net entropy, ie generate heat. The only way around this is with reversible computing, which can potentially add no entropy and no need for cooling. It’s clear why we’d reverse a class method: doing so will lower our A/C bill.
How would you count the lines in a method?
What a brilliantly subtle question! A junior programmer would use their fingers while an intermediate one would look at the line numbers, but even the best of the best would fall for the trick here. Sure, those two methods work for a method you wrote, but what about one generated at runtime? The correct answer here is you can’t: counting the lines in a method is the same as solving the Halting Problem!
If you ask this to an interviewee and she responds “that’s a stupid question”, hire her on the spot. She must have deep knowledge of Python and mathematics to see the impossibility in the question.
Explain how can convert return something even if you prevent this effect?
wat
There you have it: Ten awesome, rigorous, curated Python questions. If you’re interviewing, understanding these will ensure you get whatever programming job you desire. If you’re an interviewer, asking these will ensure only the exceptional programmers will work at your company.
Just don’t use the last one. It makes no sense.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!