List of Interview Questions

questionbox Below is a list of software engineer skills or areas that can be tested and evaluated in an interview context. Use the list below to help you get started, and you’ll soon be developing your own favorite questions and competencies for interviews.

Visit katemats for the full list of questions.

Data Structures: Trees & Graphs

  • Given a tree write breadth first search and depth first search, and explain the run time and space requirements.Convert a binary search tree into an ordered array.  How do you do this as efficiently as possible?
    • Now modify your solutions to handle trees with weighted edges and/or loops and print out the path from start to finish.
  • How do you find the 7th element in a binary search tree?  How do you generalize the function to find the Nth element?  (solution)

Data Structures: Queues & Stacks

  • Design and implement a stack. Implement the different methods: push, pop, retrieve the minimum element in constant time. (solution)
  • Design a queue using stacks as the underlying data structure (solution).  Implement a stack using queues as the underlying data structure (solution).

Data Structures: Hash Tables

  • How do hash tables work?What are some examples of real life hash tables? When is a hash table a poor data choice?
    • What are different ways of managing collisions?
    • Implement a hash table.

Teamwork & Collaboration

  • Give examples of project that were completed as a team.  Were there any that went better than others? Why? What was different?
  • What is the best way to collaborate on a coding project?
  • Have you ever had to deal with features that involved multiple people working in the same areas? How did it go? Was there anything that could have been done to improve it?
  • Do you do your best work alone or in a group?  Does the type of work matter?
  • What does it mean to be a good teammate?  Have you ever had any bad teammates? If so, did you tell them and give the feedback?

You are NOT a Software Engineer!

You are not a Software Engineer. You do not build skyscrapers. You do not build bridges.

You grow gardens.

You are a Software Gardener.


Do you try to plan your gardens in such detail that you know where each leaf will be positioned before you plant a single seed? Do people expect estimates (or are they promises in your organisation?) on exactly how many flowers will have bloomed in one years time? Do you have a bonus tied to that? Things that would be perfectly reasonable to plan for a skyscraper seem a little ridiculous when you are talking about a garden.

You probably have a good idea of what your garden should look like a week into the future. You might even have a rough idea of the shape you expect it to be in a year from now. But you have no idea of where each branch, leaf, stem and flower will be a year from now, and if you say you do then you’re really only guessing.

If you were building a bridge or a skyscraper and you told me, before you began, that you knew exactly how it would look when it was finished – I would believe you. If you told me that you knew to some insane degree of accuracy how long it would take to get to ‘finished’ – I would believe you again. That’s how Engineers roll. Tell me the same thing about your garden and I’m gonna call bullshit. Tell me you are going to make it grow faster by hiring more gardeners and I’m gonna laugh at you.

So why do so many gardens fail, yet so many skyscrapers succeed? With a few exceptions, the technique for building a skyscraper is similar whether you are in Europe or you are in Singapore. Gardens do not work that way. Every garden is different because the environment it is in is different. Even gardens that are within throwing distance of each other can have wildly different soil. That is why the lowest bidder can probably build the same bridge as the highest bidder, but your company can’t grow the calibre of gardens that Google can grow.

Remember that time when someone in your company unsuccessfully used an Agile gardening methodology, and then went around saying that it was horse shit that doesn’t work? Well horse shit does grow gardens, it just wasn’t enough to save your garden. Your garden was probably dead before it started – a victim of the climate of your organisation. Were you trying to grow a rainforest in the desert? You can’t just plant the same plants as Facebook, Flickr or Twitter and expect them to take root regardless of the quality of your gardeners or the climate of your organisation.

Unlike a skyscraper, your garden will grow weeds. It will never be ‘finished’. Just because you stop spending money on it doesn’t mean it is finished. If you stop weeding your garden the weeds will eventually smother it, and soon a re-plant will look easier than a pruning. The environment around your garden will also always be changing, and a neglected garden will become harder and harder to keep alive.

In most countries, Engineers need a license to build a bridge. Gardeners have no such government-mandated quality control. Unfortunately, the quality of your gardeners is going to have a bigger influence on your gardens success than any other factor – so you’d better be good at picking the wheat from the chaff. Only an experienced gardener really knows another good gardener when they see them. Someone who has merely managed gardening projects will have no idea what they should be looking for (though they won’t know this). So if you are not a gardener, but need to recruit good gardeners, then quickly find an experienced gardener you trust to vet your candidates. You can’t learn gardening in a classroom, so remember to focus on gardens your candidates have grown before, rather than how much gardening theory they learned at school (which nearly always won’t be applicable to the climate you are growing in anyway).

The engineering metaphor has had its time in the sun, and maybe it even used to be accurate, but now it really only serves to help non-technical people have unrealistic expectations about how software gets built.

I am a Software Gardener.

So are you.



Estimote Beacons and Stickers are small wireless sensors that you can attach to any location or object. They broadcast tiny radio signals which your smartphone can receive and interpret, unlocking micro-location and contextual awareness. With the Estimote SDK, apps on your smartphone are able to understand their proximity to nearby locations and objects, recognizing their type, ownership, approximate distance, temperature and motion.


NASA’s giant space umbrella Starshade could help find alien life. A massive screen called a starshade would be positioned in space to fly in formation with a space telescope, at an angle blocking a particular star’s light and creating a high-contrast shadow. That way, only the light of an orbiting exoplanet would enter the telescope.

Think of it as a really big beach umbrella, or perhaps the sun visors on your car windshield. But visually, it’ll probably look more like a giant flower, with metal petals along its edges to block more starlight around the possible location of an exoplanet in the sky. In 2015, engineers for aerospace contractor Northrop Grumman, which would build the starshade, tested different designs with the the earthbound McMath-Pierce Solar Telescope in Arizona. They found that petal-shaped designs worked better than a circular version.

“If we can feather the edges, soften those edges so we can control diffraction, well, then we can see a planet,” explained Princeton University aerospace engineer Jeremy Kasdin, who is helping to develop the starshade, in a 2014 TED Talk.  Also, there still are significant technical hurdles to be overcome. One big challenge: Figuring how to fly a starshade in tight formation with a telescope that’s more than 30,000 miles (48,280 kilometers) away, the distance described by Kasdin in his TED presentation. If all those details are worked out successfully, a starshade could be deployed by 2024, according to the report.