Sebastian Patten

a love of learning

Page 3 of 7

Front End Web Developer Interview Questions


  1. What technology blogs do you read?
  2. What is your favourite technology book you have read?
  3. What is the difference between progressive enhancement vs graceful degradation


  1. What is a Doctype?
  2. What would the Doctype declaration look like for HTML 5?
  3. When declaring an XHTML doctype, what would the differences be between Strict and Transitional?
  4. What are semantics in relation to HTML page layout?
  5. What is the DOM in relation to HTML?
  6. What HTML element would you use to display some bolded text?
  7. What HTML element would you use to show some definitions?
  8. What HTML element would you use to show a quote?
  9. Is HTTP a stateful or stateless protocol?
  10. Tell me what an HTTP header can contain
  11. List some of the new features in HTML 5


  1. What is “Standards Mode” and how would it be triggered?
  2. What is “Quirks Mode” and how would it be triggered?
  3. List the available options for the display property in CSS
  4. List the available options for the layout property in CSS
  5. What is the “Box Model”?
  6. What is “reset” CSS code and why would you use it?
  7. What ways can you include CSS within your website?
  8. Tell me about the “cascading” in CSS
  9. How would you select an element in IE6 only?
  10. How would you select an element in IE7 only?
  11. List as many HTML elements as you can that have a display: block setting by default
  12. List as many HTML elements as you can that have a display: inline setting by default
  13. What is Firebug?
  14. How do you go about solving really hard to fix CSS problems?
  15. List some of the new features in CSS3


  1. What is the XMLHttpRequest?
  2. What does AJAX stand for?
  3. Is Javascript Object Oriented?
  4. Why would you use jQuery?
  5. What steps would you take to debug Javascript?
  6. What is JSON and what does it look like?
  7. How would you make an AJAX call using jQuery?
  8. How would you extend jQuery to include you’re own functions?
  9. What is prototypical inheritance in JavaScript?
  10. Write JavaScript to define a Dog. The dog should have a method called “weight” that returns the dogs weight and a method called “type” that returns the dog’s type. Extend the dog to have two specializations. 1) britishBulldog 2) husky. The weight should be passed in through the constructor. The name should be overridden for each of the specializations.


  1. List some steps that can be carried out on a website that can improve its performance
  2. List some factors that affect SEO

Git Commits

GIT Tutorial: Part 3

This is Part 3 of the Git tutorial. To see the rest, click here

YouTube Video Series:

Git tracks its history using a tree structure behind the scenes. Each entry in the tree is uniquely identified with a SHA hash. When playing with Git you may have seen something like:

A list of commits, each with one parent

What you are looking at is a stack of commits where the SHA hash uniquely identifies each commit. It can be thought of as a unique identifier like a primary key in a database.

Try the following to see some commits in your repository.

git log --oneline

The oldest is at the bottom and the newest at the top. What is not obvious is that the child item has a pointer to its parent(s). In the above scenario each child has one parent and it looks just like a list. Note: In the diagram below we are using alphabet letters instead of SHA hashes.


B has a pointer to its parent A

A commit can have one or more parents. When the commit has two or more parents it is essentially a merge where we have taken content from A and B and made C.


C has a pointer to its parents, A and B


When we download a Git repository we can think of it being almost two separate items. First there are all the files in your project as then there is as an index that tracks the Sha references and which files they each relate to. This index is called the reflog. Not only does it contain these Sha references, it also can contain Tags (which are human-readable labels applied to a single Sha reference) and pointers that identify the Sha reference of each branch in the repository.

Book Recommendation

I highly recommend this book on Git as it goes really deep into how Git works and is well written.

Visualizing Git

GIT Tutorial: Part 2

This is Part 2 of the Git tutorial. To see the rest, click here

YouTube Video Series:

 Local and Remote

At a high level we will be discussing two separate instances of Git. Firstly there is the instance on your own machine which we can refer to as the local instance. Then there is the instance on some remote machine which we can refer to as the remote instance. There aren’t really any differences between the local and remote except for being on different machines. The remote instance for example could be the place where the team pushes their code to. Ultimately there usually are at least 2 Git copies, your local and somewhere that you push your copy to. Think of it like Subversion and pushing your changes to a remote repository.

Side note: quite often in documentation you will see the remote referenced as “origin” (a default name). 

Creating a Git Repository

Let’s start off by creating a brand new Git Repository.

mkdir Demo
cd Demo
git init

This creates our Demo folder and then creates a new Git repository. Simple!

Logical sections within Git

Within an instance, Git is best visualized as 3 separate buckets.


Working Directory

The working directory is what you see in your folders and file system. You make code changes here.

In the Working Directory, you might create a new file called A.txt, add some content and save it.

If we run the command

git status

This will ask Git to see what the current status is. Has anything changed? Are there any files waiting to be added to Git?

Screen Shot 2014-09-07 at 4.34.39 PM

You can see in this example, Git isn’t tracking A.txt. It also tells us how to add the file.

Staging Area

Next you would tell Git to track this new file.

git add A.txt

Alternatively you could add all files within the directory by specifying the dot syntax.

git add .

Running Git status again we see:

git status

Screen Shot 2014-09-07 at 4.38.10 PM

The whole point of the Staging Area is to create a candidate for committing to the database. Take for example fixing a bug. It would be far cleaner and easier to read 1 commit to the database e.g. “#424 Bug fixed” rather than 10 piecemeal commits all contributing to the commit. In Git we can stage and manipulate our commits to make history more logical and easier to read.

Once you are happy with your your Staged work you would commit it to the actual repository.



git commit -m "#424 Bug fixed"

Screen Shot 2014-09-07 at 4.40.22 PM

This would move our staged changes into the Repository. Essentially freezing those changes in place.

That’s it! That is a very simple example that touches upon all 3 buckets within Git.


To help visualize the bigger picture, the typical day-to-day workflow that you would use would be something like this:

  • Fetch from the database (this updates your repository and brings down all information from the centralized repository)
  • Pull to update your local copy with what is in the remote repository
  • Make some local changes
  • Add them to the Staging Area
  • Commit your Staging Area to the repository
  • Finally when you are happy with your commits, Push them to the remote instance
  • And go to step 1 again…

Don’t worry about the other verbs that we haven’t discussed yet, we’ll touch upon them in later topics.

Book Recommendation

I highly recommend this book on Git as it goes really deep into how Git works and is well written.

Distributed Version Control System


GIT Tutorial: Part 1

This is Part 1 of the Git tutorial. To see the rest, click here

YouTube Video Series:

GIT is a Distributed Version Control System (DVCS), which can be seen as a step up from a regular Version Control Systems (VCS). The “Distributed” in DVCS means that multiple copies of a repository are held rather than just the single repository.

This is good because:

  • Enhanced failover capabilities: If you loose your main repository through a catastrophic incident, you still have copies of the repository held on other machines
  • It opens the door for collaboration: In a centralized version control system, everyone has to commit and merge on the single source of truth. With a DVCS, we can have sub teams of people working on a long running sub-project. Reading and writing to each others repositories on different machines from the main repository. They can integrate their work over and over again without disrupting people working on the main repository.
  • Offline work: Means you can take your work home for the night and rather than having to wait till the next morning to commit all of your work, you can commit there and then and then just re-sync your local repository and your company’s main repository the next day.
  • Encourages Forking: GitHub has exploded with popularity and levelled up Open Source software. The reason being is that you can take someone’s work, create a copy (a Fork in GitHub land) and use that as a starting place to improve the original software (or build your own software). A DVCS allows you to download the repository of work and create your own branch and re-submit it back to the original author who can include your additions back into their own work.
Distributed model for Version Control

An example of a distributed system. One central remote supplying 3 repositories. And a side project going on.

Book Recommendation

I highly recommend this book!

Node.js sharing JavaScript code between client and server

I first looked at Node.js because it sounded like they had bridged the gap between client side (browser) and server side (Node.js) aka Isomorphic JavaScript. Code re-use is one of the core principles of developing software and for some reason it has taken us this long to get to a point where we can write one language that can be reused on both server and client side.

My initial impressions of Node.js bridging this gap weren’t great. Node.js does a good job of running stuff server side in JavaScript, but finding documentation on how to share code has been a slow process. The documentation on their website doesn’t mention sharing of code between client and server.

Current state of affairs

Node’s server side code exposes public methods/properties with a module pattern

If you want to expose a public method called doCoolStuff in your Awesome.js file you might do this:

exports.doCoolStuff = function() {

// Cool stuff done here...


However when we go to run Awesome.js on the client – it’s not going to know anything about what an exports is.


There are various ways around this such as checking whether exports exists, if it doesn’t define it etc… (read more here)

My preferred solution is to use Require.js and kill many birds with one stone. From the web browser point of view, Require.js is really helpful in that it:

  • Allows us to asynchronously load JavaScript resources
  • Allows you to get rid of script includes from your HTML
  • Negates the issue of having to order JavaScript files one after the other
  • Greatly improves on the ability to test our code by swapping out concrete implementations with mocks/dummys
  • Cleans up your code a lot
  • Better way of specifying modules

Also we can use the same code on the client and server (Node.js).

Setting up the Server Side (Node.js)

I tried to install via NPM a la – npm install requirejs, however NPM couldn’t download and unpack the files for some reason.

To get around this I downloaded the r.js code for node directly from the Require website, renamed to index.js and placed it in a folder called Requirejs in the node_modules folder. I renamed it to index.js as node will automatically look for a file called index.js in folders in node_modules.

Server Side Code – Server.js

var requirejs = require('requirejs');

// Boiler plate stuff - as per r.js's instructions
    //Pass the top-level main.js/index.js require
    //function to requirejs so that node modules
    //are loaded relative to the top-level JS file.
    nodeRequire: require

// We are requiring Person, instantiating a new Person and then
// reading the name back

// As Person.js is a module, we dont need the .js at the end
requirejs(["/Path/To/Person"], function(Person) {
	var person1 = new Person("Seb");

Code that can live on client or server – Person.js

define(function() {
	return function(firstName) {
		var _firstName = firstName;

		this.getFirstName = function() {
			return _firstName;


<!DOCTYPE html>
        <title>My Sample Project</title>
        <!-- data-main attribute tells require.js to load
             scripts/main.js after require.js loads. -->
        <script data-main="scripts/main" src="scripts/require.js"></script>
        <h1>My Sample Project</h1>

JavaScript for the HTML Page – Main.js

// We are requiring Person, instantiating a new Person and then
// reading the name back

// As Person.js is a module, we dont need the .js at the end
require(["/Path/To/Person"], function(Person) {
	var person1 = new Person("Seb");

More Reading

There are some rules around relative paths for your requires. It’s well worth spending the time and reading over them at the Require.js website.

Require.js talking about what Asynchronous Module Definition is

« Older posts Newer posts »

© 2019 Sebastian Patten

Theme by Anders NorenUp ↑