Programming interview glossary

This blog post explains most of the popular keywords I was asked about during interviews for the various software engineering roles. They are presented in an alphabetical order. Personally I find this glossary very useful when preparing for the upcoming interview.

Agile Software Development

In 2001 a group of industry experts created a statement of values called The Manifesto of the Agile Alliance:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The professional goal of every software developer is to deliver the highest possible value to their employers and customers. The principles of agile software development were formed to simplify complicated processes and to focus on reaching their goals. There are many agile processes to choose from. Those includes SCRUM and eXtreme Programming.

BDD

Behavior-driven development (BDD) is a refinement of practices coming from TDD (Test Driven Development) and ATDD (Acceptance Test Driven Development). During the “Agile specifications, BDD and Testing eXchange” in November 2009 in London, Dan North gave the following description:

BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

BDD uses specialized tools to add automation to the ubiquitous language that is a central theme of BDD.

Design Patterns

Design patterns are recurring solutions to common problems in software design. Design patterns gained popularity in computer science after the book Design Patterns: Elements of Reusable Object-Oriented Software was published in 1994 by the so-called “Gang of Four” (Gamma, Helm, Johnson and Vlissides), frequently abbreviated as “GoF”.

• Creational Patterns – create objects for you, rather than having you instantiate objects directly. This gives your program more flexibility in deciding which objects need to be created for a given case.
  • Abstract Factory – groups object factories that have a common theme.
  • Builder – constructs complex objects by separating construction and representation.
  • Factory Method – creates objects without specifying the exact class to create.
  • Prototype – creates objects by cloning an existing object.
  • Singleton – ensures a class has only one instance and a global point of access.
• Structural Patterns – these concern class and object composition. They use inheritance to compose interfaces and define ways to compose objects to obtain new functionality.
  • Adapter – allows classes with incompatible interfaces to work together by wrapping its own interface around that of an already existing class.
  • Bridge – decouples an abstraction from its implementation so that the two can vary independently.
  • Composite – composes zero-or-more similar objects so that they can be manipulated as s )one object.
  • Decorator – dynamically adds/overrides behaviour in an existing method of an object.
  • Facade – provides a simplified interface to a large body of code.
  • Flyweight – uses sharing to support large numbers of fine-grained objects efficiently.
  • Proxy – provides a placeholder for another object to control access to it.
• Behavioral Patterns – most of these design patterns are specifically concerned with communication between objects.
  • Chain of Responsibility – delegates commands to a chain of processing objects.
  • Command – creates objects which encapsulate actions and parameters.
  • Interpreter – implements a specialized language.
  • Iterator – accesses the elements of an object sequentially without exposing its underlying representation.
  • Mediator – allows loose coupling between classes by being the only class that has detailed knowledge of their methods.
  • Memento – provides the ability to restore an object to its previous state (undo).
  • Observer – publish/subscribe pattern which allows a number of observer objects to see an event.
  • State – allows an object to alter its behavior when its internal state changes.
  • Strategy – allows one of a family of algorithms to be selected on-the-fly at runtime.
  • Template Method – defines the skeleton of an algorithm as an abstract class, allowing its subclasses to provide concrete behavior.
  • Visitor – separates an algorithm from an object structure by moving the hierarchy of methods into one object.

DRY

This is acronym for “Don’t repeat yourself”. The DRY principle is stated as:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

It came up in the book The Pragmatic Programmer, by Andy Hunt and Dave Thomas. When the DRY principle is applied successfully, a modification of any single element of a system doesn’t require a change in other logically unrelated elements. Additionally, elements that are logically related all change predictably and uniformly, and are thus kept in sync.

KISS

This is an acronym for “Keep it simple, stupid”. It states that most systems work best if they are kept simple rather than made complicated. The main goal in design should be simplicity and unnecessary complexity should be avoided. First noted as a design principle by U.S. Navy in 1960.

OOD

Object-oriented design (OOD) is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design.

OOP

Object-oriented programming (OOP) uses a different set of programming languages than old procedural programming languages (C, Pascal, etc.). Everything in OOP is grouped as self sustainable “objects”. You gain reusability by means of four main object-oriented programming concepts:

• Encapsulation (also called Information Hiding) – the idea is to hide how a class does its business, while allowing other classes to make requests of it.
• Abstraction – it places the emphasis on what an object is or does rather than how it is represented or how it works. It reduces complexity by hiding irrelevant detail.
• Inheritance – the ability of a new class to be created, from an existing class by extending it or overriding its functionality.
• Polymorphism – the ability to replace an object with its subobjects. The ability of an object-variable to contain, not only that object, but also all of its subobjects.

SOLID

SOLID is an acronym introduced by Michael Feathers for the “first five principles” named by Robert C. Martin in the early 2000s that stands for five basic principles of object-oriented programming and design. Those principles help developers eliminate design smells and build the best design for the current set of features. When applied together, intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time. There are as follows:

• The Single Responsibility Principle (SRP) – A class (component) should have one, and only one, reason to change.
• The Open-Closed Principle (OCP) – A system should be open for extension, but closed for modification.
• The Liskov Substitution Principle (LSP) – Subtypes should be substitutable for their base types.
• The Dependency Inversion Principle (DIP) – Abstractions should not depend upon details. Details should depend upon details.
• The Interface Segregation Principle (ISP) – Interfaces should be small, focused on a specific use case.

TDD

Test-driven development (TDD) is an approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and finally refactor the new code to acceptable standards. Kent Beck, who is credited with having rediscovered the technique, stated in 2003 that TDD encourages simple designs and inspires confidence. TDD cycle:

1. Add a test.
2. Run all tests and see if the new one fails.
3. Write production code.
4. Run tests – if any test fails go to 3.
5. Refactor code.
6. Repeat the cycle.

XP

Extreme Programming (XP) is the most famous of the agile methods. It is made up of a set of simple practices. These practices work best when combined together:

• Whole Team – all the contributors to an XP project work together in an open space. Each one can see charts and other evidences of their progress.
• Planning Game – planning is continuous and progressive. Every two weeks developers estimate the cost of candidate features, and customers select those to be implemented.
• Customer Tests – the customers define automated acceptance tests for each desired feature.
• Simple Design – the team keeps the design exactly suited for the current functionality of the system.
• Pair Programming – all production software is built by two programmers, sitting side by side, at the same machine.
• Test-Driven Development – the programmers work in very short cycles, adding a failing test, then making it work.
• Design improvement – don’t let the sun set on bad code. Keep the code as clean and expressive as possible.
• Continues Integration – the team keeps the system fully integrated at all times.
• Collective Code Ownership – any pair of programmers can improve any code at any time.
• Coding Standard – all the code in the system looks as if it was written by a single very competent individual.
• Metaphor – the team develops a common vision of how the program works.
• Sustainable Pace – the team work hard at a pace that can be sustained, treating the project as a marathon rather than a sprint.

YAGNI

This acronym stands for “You aren’t gonna need it”. This is a principle of Extreme Programming that states a programmer should not add functionality until it became necessary. It means you shouldn’t overengineer something based on what you think you might need later on. XP co-founder Ron Jeffries has written:

Always implement things when you actually need them, never when you just foresee that you need them.

References

1. Agile Software Development, Principles, Patterns and Practices – Robert C. Martin (2002)
2. Design Patterns: Elements of Reusable Object-Oriented Software – Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1994)
3. Wikipedia