May 12, 2014

Python and Django Interview Questions

Django Interview Questions 
Following commands are used to install django on your machine :

> mkdir code ; cd code
> apt-get install python-pip python-virtualenv virtualenvwrapper 

> mkvirtualenv some-django-project  

> pip install django 
> django-admin startproject somedjangoproject  

> cd somedjangoproject 
> python startapp app1 

Following are the random questions which are asked during django interviews

  • What Data Model Django follow?
  • Describe how Django is MVT?
  • What are the named url patterns? What is the url template tag and what is its usefulness?
  • Tell me about a templating system in Django. What is template inheritance? How do you get contents of a parent block?
  • What is a template tag? What is an inclusion template tag? How do you create a template tag?
  • What is ORM? Why is it useful? How does Django accomplish such functionality? What is model inheritance? What types of model inheritance are there in Django?
  • In table inheritance, how are the two tables related?
  • How do you extend a user profile in Django?
  • Describe signals in Django? What is their usefulness? What design pattern do they remind you of? How would you implement the above mentioned design pattern? 

  • What's the difference between django OneToOneField and ForeignKey?
Ans : OneToOneField

A one-to-one relationship. Conceptually, this is similar to a ForeignKey with unique=True, but the "reverse" side of the relation will directly return a single object.
In contrast to the OneToOneField "reverse" relation, a ForeignKey "reverse" relation returns a QuerySet.


For example, if we have the following two models (full model code below):
  1. Car model uses OneToOneField(Engine)
  2. Car2 model uses ForeignKey(Engine2, unique=True)
From within python shell execute the following:

OneToOneField Example

>>> from testapp.models import Car, Engine
>>> c = Car.objects.get(name='Audi')
>>> e = Engine.objects.get(name='Diesel')
<Car: Audi>

ForeignKey with unique=True Example

>>> from testapp.models import Car2, Engine2
>>> c2 = Car2.objects.get(name='Mazda')
>>> e2 = Engine2.objects.get(name='Wankel')
>>> e2.car2_set.all()
[<Car2: Mazda>]

Model Code

from django.db import models

class Engine(models.Model):
    name = models.CharField(max_length=25)

    def __unicode__(self):

class Car(models.Model):
    name = models.CharField(max_length=25)
    engine = models.OneToOneField(Engine)

    def __unicode__(self):

class Engine2(models.Model):
    name = models.CharField(max_length=25)

    def __unicode__(self):

class Car2(models.Model):
    name = models.CharField(max_length=25)
    engine = models.ForeignKey(Engine2, unique=True)

    def __unicode__(self):

Complete the following Django model to illustrate how a manufacturer can make many different types of cars.
Give manufacturer a name, founding date and a country.
Give car a name, cost, engine capacity and color. Assume that the manufacturer makes cars in only {red, green, blue and pink}.
class Manufacturer(models.Model):
    # A car manufacturer

class Car(models.Model):
    # A type of car

A user types the following URL into their browser:
Explain in detail how this would cause a page to appear in their browser, with images, interactive elements (Ajax), styled paragraphs of text etc.
What is a generic view in Django? What generic views ship with Django? What do they do?
Explain what the following Django model code does? What's the relationship between topping and pizza?
class Topping(models.Model):
    # ...

class Pizza(models.Model):
    # ...
    toppings = models.ManyToManyField(Topping)

What is a signal in Django? Where might you use one? What's the difference between send() and send_robust()? When might you use one over the other?
What does the following code do? What's another way of doing the same thing?
from django.core.signals import request_finished
from django.dispatch import receiver

def my_callback(sender, **kwargs):
    print "Request finished!"

Complete the following Django form to include:
  • subject with a maximum length of 100 characters
  • An optional, boolean, cc_myself field
  • sender field that will be validated as a correctly formatted email address
from django import forms

class ContactForm(forms.Form):
    message = forms.CharField()

Describe the MVC design pattern and how you might use it in practice.
Implement it.
Django interview questions:
  1. Start off with some basic SQL such as SQL Skills: Joins, Averages and Sums
  2. Include at least one simple coding task such as Separate a list of integers or Find the missing number
  3. Explore their ability to come up with an overall system design and data model with a flexible question likeDesign a restaurant reservation system or Design a card game system
  4. Ensure that they have a solid understanding of the basic building blocks of the web by asking about HTTP GET and POST or What are HTTP cookies?
  5. Test their knowledge of Python basics by asking them about What is a list comprehension?Tuples and lists, and Slicing lists .
  6. Test their Django specific knowledge with questions on Django viewsDjango ModelsDjango Forms andDjango Signals.
  7. Wrap up with some CSS questions like Explore the HTML display and position attributes or CSS rule-set basics
What kind of calling model does Python use?
  • What most people say: “Python uses call-by-reference,” or, “Python uses call-by-value.”
  • What you should say: “Actually, Python uses call-by-object.”
  • Why you should say it: This question separates the veterans from the rookies, according to Wendt. Only developers with considerable hands-on experience typically know about Python’s unique calling model. 
What is Unicode, what is UTF-8 and how do they relate?
  • What most people say: “Unicode has something to do with special characters, right?”
  • What you should say: “Unicode is an international encoding standard that works with different languages and scripts. It consists of letters, digits or symbols representing characters from across the world. UTF-8 is a type of encoding, a way of storing the code points of Unicode in a byte form, so you can send Unicode strings over the network or store them in files.”
  • Why you should say it: Since developers must create code for a world comprised of many cultures and languages, you should know how to develop an application that will be used by non-English speakers. Knowing about Unicode/UTF-8 shows that you understand the importance of global development protocols.
How do you decide when to reuse code and when to start from scratch?
  • What most people say: “I typically search GitHub, Bitbucket and PyPI (Python Package Index). If I find something I like, I’ll copy the code. If I don’t find a viable solution online, I’ll create fresh code.”
  • What you should say: “Creating brand new code is a last resort. I’ll research code libraries, using several criteria to decide whether I should integrate existing code into my project. For instance, I’ll consider the quality of the code, the reputation and activity of the developer as well as the efficacy and size of the coding community. I want to know whether the developer is generating timely updates and notes, how quickly bugs are being fixed, and whether the code has received recent updates.”
  • Why you should say it: A good engineer’s goal is to write and maintain the least possible amount of code so that they can focus on other things, like making their product unique. However, the decision to incorporate existing code requires careful consideration. If you’re unable to find a quality solution online, sometimes it’s better to rethink the problem.
How would you scale an existing application when starting a new project?
  • What most people say: “I’d use a NoSQL data store to store my data. Also, I’d cache a good portion of the data in Redis or Memcached through Django’s caching facilities. Perhaps I’d put a reverse proxy like Varnish in front of it.”
  • What you should say: “I see performance and scaling as two separate things. Performance is how fast a user is served and scaling refers to the number of users that can be served by an app at the same time. Usually, time is best spent developing during the early stages of a project. When scale does become an issue, usually business is good and there are sufficient funds to optimize the application.”
  • Why you should say it: First of all, as an engineer it’s always good to take a step back and analyze the question instead of jumping to conclusions. The best way to answer this one is by explaining what scaling is and to question whether it’s required in the early stages of a project. A good engineer asks the right questions before rendering a decision. These are the type of characteristics employers are looking for.
Are there situations where you wouldn’t use Python/Django?
  • What most people say: “Not really. Python is a very good, generic programming language and Django has so many options, that it works for any Web application.”
  • What you should say: “Sure. For example, if a project involves some kind of reasoning it might be better to use Prolog and have Python interface with it. Of course, I would be mindful about adding more complexity to the stack by introducing a new language.”
  • Why you should say it: Every programming language or framework has its strengths and weaknesses. Good engineers don’t become emotionally attached to a language, and weigh several options before making a decision. However, they also realize that adding a new programming language increases complexity. So, they constantly ask themselves if adding another language is really worth it.

March 25, 2011

19 Guidelines for creating good Open Source Software

I really admire Eric .S . Raymond by the fact that how he overcame his childhood problem  and used it to his advantage and converted that stumbling block for the stepping stone of his success. He suffers from  congenital cerebral palsy which motivated him to chase a future in computing.
      Got a chance to read his well known book " The Cathedral and the Bazaar " based on his observations of the Linux kernel development process and his experiences managing an open source project, fetchmail.

I really liked the 19 points which he has mentioned in the book as guidelines for creating a good open source software and those are as follows:-

There are 19 guidelines for creating good open source software listed in his essay:
  1. Every good work of software starts by scratching a developer's personal itch.
  2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
  3. Plan to throw one away; you will, anyhow.
  4. If you have the right attitude, interesting problems will find you.
  5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
  6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
  7. Release early. Release often. And listen to your customers.
  8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
  9. Smart data structures and dumb code works a lot better than the other way around.
  10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
  11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
  12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
  13. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
  14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
  15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
  16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
  17. A security system is only as secure as its secret. Beware of pseudo-secrets.
  18. To solve an interesting problem, start by finding a problem that is interesting to you.
  19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
Hope everybody will like it. These points are really very helpful not only to improve ourself on professional front but also on personal front.