Tag Archives: architecture

Software Engineering Interview Questions

Edit, 6/26/2012:
This post is my personal rant about interview questions. If you got here looking for actual programming interview questions, I can recommend these books: Cracking the Coding Interview and Programming Interviews Exposed. These books helped many engineers getting their dream jobs.

It’s no secret I’ve been in a lot of interviews in the past couple of years, both as an interviewer and as a candidate. When it comes to tech interview questions, to simplify things, I can break it into 3 major types:

  1. Implementation questions
  2. Architecture/design questions
  3. “Problem solving” questions

The first type intends to check your experience with current industry standard tools. For instance, as a javascript engineer you will be asked about specific jQuery method, what problem it designed to solve, and how you can effectively use it, how a web browser works, or what is the HTTP protocol.

The second type intends to check your software design skills, and your ability to design a complex application. As a front end engineer, you will probably asked about MVC concepts, RESTful architecture, or design patterns.

The third type intends to check how well you handle with random problems you didn’t expect. However, in many cases, this part is a tricky, and mostly out of scope.
It’s not that I don’t think a good engineer should have strong “problem solving” skills. I do.
I just think most of these “problems” you are being asked about has nothing to do with what most of us actually do on a daily basis.

In my past interviews I was asked algorithmic questions, mathematical/geometry questions and physics questions. Hell, I’m surprised I wasn’t asked to solve rocket science problems. After all, my “problem solving skills” are being measured.
Continue reading

Book Review: RESTful Web Services

 I’m working on a project that includes writing a client for a fairly sophisticated RESTful API.

To get some better understanding of both client and server RESTful philosophy I purchased and read RESTful Web Services by Leonard Richardson, Sam Ruby (O’Reilly Media, 2008).

I tend to agree with the foreword by David Heinemeier Hansson: “Every developer working with the Web needs to read this book.”

The web is RESTful and therefor, when working with the web one shall at least understand RESTful concepts.

This book is doing a great job describing to details the concepts of addressability, statelessness, connectedness, and the uniform interface, and clarifying why they are important fundamentals of the web.
It gives a great overview of HTTP, URIs, Design of a REST server and client.

If I had to take one thing from the book, I would take the importance of state management.
It is crucial to understand where the state of the application belongs to.
Saving the application state on the back-end breaks the stateless nature of a web app, and could end up with an application that is hard to maintain and scale.
Keeping the state in the client side (or even better – in the URI), and keeping a sane, loosely coupled design leads to scalable web application.

One thing I was not very impressed with are the code examples.
I skipped most of them, since I didn’t buy this book to learn how to implement a REST server using RoR or Django, but choosing XHTML as the document format is very odd, and using a <div> or a <span> to represent semantic data is even odder.
Calling HTML5 XHTML5 is annoying, but given this was published in 2008 I given it the benefit of the doubt.

Bottom line, this was a good read and I highly recommend it.
If you are looking for a book to give you some detail oriented overview of REST concepts, this book is for you.

Javascript Design Patterns: Strategy

For a quick assignment I was asked to write the following program:

In the language of your choosing build an application that, given an English language document as input, builds a data structure capturing the count of each word in the document.

Bonus:
Create an inverted index as well: a mapping of the words to absolute positions in the document.

As context, this is a foundational algorithm for search systems and information retrieval. Be sure to consider accuracy, complexity, and intent in the design of your program.

The last phrase was the one that got me thinking.
This sounded a little vague, so I started thinking what kind of design I can implement that would be flexible enough so I can apply the algorithms later.
This kind of program usually runs on the back end using Java/Python/etc, but obviously, the language of my choice was javascript.

I started by defining a master processor:

var Processor = function(doc) {
    this.doc = doc;
};
Processor.prototype.parse = function(parser, sorter) {
    data = parser.parse(this.doc);
    if (sorter && typeof sorter.sort === 'function') {
        return sorter.sort(data);
    }
    else {
        return data;
    }
};

This processor gets a document (in our simple example, a long string) and has parse method, which accepts a “parser” object that has a parse() method and an optional “sorter” object that has a sort() method.
As the names suggest, the former will parse the document, and the latter will sort the results.
This use of the Strategy Design Pattern will allow the application to be flexible for algorithm changes, in the future.

First, I defined an abstract Parser object.
This object is responsible to convert the input to a standard format, and apply an algorithm

var Parser = function(){};
/**
 * The implementation will return an object literal 
 * with the format {word: num, word: num ...}
 * 
 * @param str {String}
 * @returns {Object}
 */
Parser.prototype.parse = function(str){
    throw 'please extned abstract object';
};

/**
 * Convert an object literal into a sortable array
 * with the format [[word, num], [word, num], ...]
 * 
 * @param data {Object}
 * @returns {Array}
 */
Parser.prototype.convert = function(data) {
    var arr = [],
        data = data || {};
    for(var key in data) {
        if(data.hasOwnProperty(key)) {
            arr.push([key, data[key]]);
        }
    }
    return arr;
};

My next step was defining the parsers I was requested to write:
One for capturing the count of each word in the document:


var CountParser = function(arr) {
this.arr = arr;
};
CountParser.prototype = new Parser; // extend the base parser
CountParser.prototype.parse = function(str) {
var value, i, l, data = {},
arr = str.split(/[\s]+/);
for(i=0, l=arr.length; i