The Curious Programmer

Software, Gadgets, Books, and All Things Geek

A Pragmatic View on Patterns — March 25, 2015

A Pragmatic View on Patterns


WARNING: Below contains strong opinions that you may not agree with! Read at your own risk…(and if you disagree, tell me why I’m wrong in the comments! I have an open mind 🙂 )

In my last post I wrote about 12 Influential Books Every Software Engineer Should Read. I hope most people found it helpful and would love to hear about any other books you would like to have added to the list. There was one book, however, that received more controversy than rest. This book was “Design Patterns: Elements of Reusable Object-Oriented Software”.

Some people who read the post believed that knowing design patterns was not a fundamental or crucial skill to being a good software engineer or programmer. Others believed it was more important than all of the rest of the books and were mad that I had listed the book as “Number 10” instead of “Number 1”.

In this post I’ll give my 2 cents about design patterns and I’m sure just as many people will disagree with me about the thoughts I have on the subject. (I’m okay with that)

Lets first define what we are actually talking about because there are lots of definitions of design patterns on internet but Christopher Alexander (who is a famous architect noted for his theories about design) says, “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it in the same way twice”

In simplest way “A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design“.

In general, a pattern has four essencial elements:

  • Pattern Name
  • Problem
  • Solution
  • Consequences

Patterns in the software community seem to be all over the place. There are patterns for everything it seems. The book “Design Patterns”, that I wrote about in my previous post, is 400 pages and doesn’t cover nearly all of them. So how do you know when and where to use a pattern and how much stock do you put into this? Am I not a good developer if I don’t understand and use all of the patterns? Am I a great one if I do?

Design patterns are both praised and criticized in the development community. My own perspective has changed throughout the years. I strongly believe that knowledge of design patterns is required. Just as we learn algorithms we should study design patterns to understand how potential problems could potentially be solved.

But that is where we need to stop.

Blindly pushing patterns into the code will increase complexity, introduce bugs, and create a maintainability nightmare. Instead, we should understand the underlying principles and ideas to apply them or build upon them as needed. As Jeff Atwood, author of “The Coding Horror” technical blog and the co-founder of the popular site, says:

“Design Pattern are a form of complexity. As with all complexity, I would rather see developers focus on simpler solutions before going to a complex recipe of design patterns.”

If you find yourself frequently writing a bunch of boiler plate design pattern code to deal with a reoccurring design problem, that’s not good engineering, its a sign that your language is fundamentally broken.

The author of “Higher-Order Perl”, Mark Dominus, also believes that the patterns obstruct the ideas of Christopher Alexander and others. In his article about design patterns, he points out that although the movement was inspired by the pattern language work of Christopher Alexander, it isn’t much like anything Alexander suggested. In fact, what Alexander did suggest is more interesting and would probably be more useful for programmers than what the design patterns movement chose to take.

He makes the same point that Jeff Atwood makes, in that the patterns that are used recurrently in one language may be invisible or trivial in another, and that many patterns aren’t really addressing reoccurring design problems in object oriented programs, they are actually addressing deficiencies in object oriented program languages. He makes the point that instead of seeing the use of design patterns as valuable in itself, it should be widely recognized that each design patterns is failure of the source language.

I personally see the truth somewhere in the middle. As programming languages evolve, we will see more and more languages with built in patterns. At the same time, more and more patterns will emerge as the new problem spaces develop. The cycle will continue and for a person to be a well rounded developer or architect it would be necessary to learn and understand modern and classical patterns. It is also crucially important to understand patterns even if they are natively built into languages. An example is IEnumerable in C#: Without a clear understanding of the Iterator Pattern and its implementation in C#, developers often make costly assumptions. In many cases such code was indeed the performance bottleneck for the entire application.  The Microsoft® .NET Framework base class library (BCL) already makes extensive use of patterns, and you are probably familiar with the most common ones, even though you might not realize it yet.

I think a good thing to keep in mind, especially for someone just learning design patterns, is that a pattern is a state of mind, mostly. Don’t ever try to force your code into a specific pattern, rather notice which patterns start to crystalise out of your code and help them along a bit.

Deciding “ok, I’m going to write a program that does X using pattern Y” is a recipe for disaster. It might work for hello world class programs fit for demonstrating the code constructs for patterns, but not much more.

I hope you enjoyed this post and if you think this is completely absurd then let me know in the comments! (or if you liked it that would be nice too haha)

12 Most Influential Books Every Software Engineer Needs to Read — March 16, 2015

12 Most Influential Books Every Software Engineer Needs to Read

This is a question that I get a lot, especially from co-workers or friends that are just beginning their journey as a software craftsman.

What book should I read to become a better developer? Do I need to read books?

I think it’s a great question, and it is one that I asked many of my mentors as I was becoming a software engineer. The problem was that many people suggested different books on different topics. All the books they suggested were great in their own right, but no one was able to give me a list that would be the ESSENTIAL books, the MUST READS, that any engineer with hopes of being great should most certainly read.

Well, I’ve learned a lot from my mentors and realized that I still had a lot to learn with the many different books that were suggested to me. I decided to develop a routine to read one book a month in my profession field (software engineering). Over the years, I’ve aggregated a list that, I believe, to be MUST READS for anyone that wants to be a top tier developer.

Now let me state the obvious – just reading all of these books on the list will not make you a great developer. That will come with years of experience and applying the principles in these books into real practices and developing your problem-solving skills in the real world.

However, reading these books will help you avoid the major pitfalls and mistakes that many developers make early off in their careers. I wish that someone would have told me about these books just starting out, but I was lucky enough to have found and read them over the years. You might have read some of these books in college for your computer science or engineering classes. Maybe at the time, you didn’t think they were important, but I can say first hand that I’ve used and applied many principles from each and every one of these books.

Let me also point out that this is not an exhaustive list. Many great books come out every year. These are just the ones that have had the biggest impact on myself and my career. Also, these are mostly language agnostic, and can be applied using any of the many software languages.  (I will do another post with the best books targeted at certain technology platforms and stacks)

Well, let’s get to it then! (drum roll, please)


(All these are essential, but I put them in descending order from which ones had the biggest impact on me. I have also provided the link (click on the book cover) to where you can purchase the book on Amazon if interested. Read the reviews and decide for yourself!)

download (3)  12. Working Effectively with Legacy Code

I love this book because almost every software developer, at some point in their career, has to support and work with a legacy system. In this book, Michael Feathers offers start-to-finish strategies for working more effectively with large, untested legacy code bases. This book draws on material Michael created for his renowned Object Mentor seminars: techniques Michael has used in mentoring to help hundreds of developers, technical managers, and testers bring their legacy systems under control.

51WIpM70FEL._SL160_  11. The Mythical Man-Month

This book is a classic, but recently revised and corrected. The amazing thing is how relevant the book still is to software product development. If you are involved in software, this book is a must-read. The most valuable part of the book, I believe, is the “plan to throw out” prototype chapter. While the goal is always to make a bigger, better, fast whatever, it is almost an axiom that you WILL build something that has to be discarded and reworked. This happens every time, I can tell you from first-hand experience. Therefore, it is vital to plan to throw out so you can migrate your users to whatever will follow. If you dream that the first product is THE ONE, you risk abandoning them on a product that will inevitably evolve. Planning to throw-away also helps meet the schedule goals by setting reasonable milestones that can be obtained.

download (2)  10. Design Patterns

If you are planning to be an architect or designer of a system, you will most likely be required to read this book. Hailed as one of the greatest software development books ever written, this book goes into great detail on the many different design patterns that have been developed over the years to help software engineers avoid and handle common problems that the industry faces. Following the strategies in this book will allow you to build higher quality, flexible, and maintainable software. This book also goes by the name “Gang of Four” in software groups because of its famous four authors that put this book together.

 pp2e  9. Programming Pearls (2nd Edition)

This book is slightly different from the other books on the list. I would say this book helps a person “think like a programmer”. Programming Pearls is a compendium of 15 columns previously published in Communications of the ACM. The columns cover a broad range of topics related to programming: from requirements gathering to performance tuning. The focus is primarily on coding techniques and algorithms.

Each column has been reorganized as a chapter. Chapters usually start with the presentation of a practical problem. Then various solutions are presented and are used as lessons to be learned. The writing style is clear and fun.

Programming Pearls is not a usual book teaching new programming concepts. Although it contains good and sometimes quite novel ideas, the aim of the book is not to teach something new but to help you become a better problem solver.

31GBgcA5PML._SL160_   8. CODE: The Hidden Language of Computer Hardware and Software

This book cleared up a lot of the “Magic” that goes into creating and developing complex systems. There are so many abstractions these days that the low-level details are sometimes unknown to the developer. Though you may not find yourself using this book 24/7 in practice…I believe it is a good idea to have an understanding of what you are building on top of and how the whole orchestration works. It may come in handy when you need to open up that “Black Box” and deep dive into the software or hardware to fix a pesky bug. “CODE: The Hidden Language of Computer Hardware and Software” by Charles Petzold deals with a number of programming concepts starting from number systems – decimal, octal, binary to high-level languages. The book explains packet based communication protocols and TCP. Many chapters are about hardware concepts, and five chapters are devoted to software and teach about the operating system, floating point arithmetic, and GUIs.

41Jon2rS8nL._SL160_  7.The Art of Computer Programming

This is another classic. This was written by the famous computer scientist Professor Donald Knuth and is highly praised by many of the top programmers in the industry. Even Bill Gates is quoted saying

If you think you’re a really good programmer… read [Knuth’s] Art of Computer Programming… You should definitely send me a resume if you can read the whole thing.”

The book begins with basic programming concepts and techniques, then focuses more particularly on information structures–the representation of information inside a computer, the structural relationships between data elements and how to deal with them efficiently. Elementary applications are given to simulation, numerical methods, symbolic computing, software, and system design.

51T4YZ3HieL._SL160_  6. Refactoring

“Refactoring” by Martin Fowler is about improving the design of existing code. It is the process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure. With refactoring, you can even take a bad design and rework it into a good one. This book offers a thorough discussion of the principles of refactoring, including where to spot opportunities for refactoring, and how to set up the required tests. There is also a catalog of more than 40 proven refactorings with details as to when and why to use the refactoring, step by step instructions for implementing it, and an example illustrating how it works The book is written using Java as its principal language, but the ideas apply to any OO language.

41znMZniZ1L._SL160_  5. Clean Code

“Clean Code,” written by Robert C. Martin, is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code—of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.

41kXXE4mAKL._SL160_  4. Introduction to Algorithms

This has to be the single best book for understanding and using algorithms (which you will be doing a lot of in software development). Some books on algorithms are rigorous but incomplete; others cover masses of material but lack rigor. Introduction to Algorithms uniquely combines rigor and comprehensiveness. The book covers a broad range of algorithms in depth, yet makes their design and analysis accessible to all levels of readers. Each chapter is relatively self-contained and can be used as a unit of study. The algorithms are described in English and in a pseudocode designed to be readable by anyone who has done a little programming. The explanations have been kept elementary without sacrificing depth of coverage or mathematical rigor.The first edition became a widely used text in universities worldwide as well as the standard reference for professionals. The second edition featured new chapters on the role of algorithms, probabilistic analysis, and randomized algorithms, and linear programming.

41AJV8G0ZTL._SL160_  3. Structure and Interpretation of Computer Programs

With an analytical and rigorous approach to problem solving and programming techniques, this book is oriented toward engineering. Structure and Interpretation of Computer Programs emphasizes the central role played by different approaches to dealing with time in computational models. Its unique approach makes it appropriate for an introduction to computer science courses, as well as programming languages and program design. The book further explains the four best-known paradigms of programming languages – imperative, object-oriented, logic based and applicative programming.

41HXiIojloL._SL160_  2. Pragmatic Programmer

This was one of the first programming books I read. I had a friend recommend it to me in my first professional job. I’m glad he did. Though the book was written in 1999 (I believe), the concepts are the basis of how we go about developing a complex system in a practical manner. Programmers are craftspeople trained to use a certain set of tools (editors, object managers, version trackers) to generate a certain kind of product (programs) that will operate in some environment (operating systems on hardware assemblies). Like any other craft, computer programming has spawned a body of wisdom, most of which isn’t taught at universities or in certification classes. Most programmers arrive at the so-called tricks of the trade over time, through independent experimentation. In The Pragmatic Programmer, Andrew Hunt and David Thomas codify many of the truths they’ve discovered during their respective careers as designers of software and writers of code.

Some of the authors’ nuggets of pragmatism are concrete, and the path to their implementation is clear. They advise readers to learn one text editor, for example, and use it for everything. They also recommend the use of version-tracking software for even the smallest projects and promote the merits of learning regular expression syntax and a text-manipulation language. Other (perhaps more valuable) advice in the book is more light-hearted. In the debugging section, it is noted that “if you see hoof prints think horses, not zebras.” That is, suspect everything, but start looking for problems in the most prominent places. There are recommendations for making estimates of time and expense, and for integrating testing into the development process. You’ll want a copy of The Pragmatic Programmer for two reasons: it displays your own accumulated wisdom more clearly than you ever bothered to state it, and it introduces you to methods of work that you may not yet have considered.

51nWkLCu1SL._SL160_  1. Code Complete 2

And this is it! The number one book (IMHO) to read if you are going to be a great software engineer. Widely considered one of the best practical guides to programming, Steve McConnell’s original CODE COMPLETE has been helping developers write better software for more than a decade. Now this classic book has been fully updated and revised with leading-edge practices—and hundreds of new code samples—illustrating the art and science of software construction. Capturing the body of knowledge available from research, academia, and everyday commercial practice, McConnell synthesizes the most effective techniques and must-know principles into clear, pragmatic guidance. No matter what your experience level, development environment, or project size, this book will inform and stimulate your thinking—and help you build the highest quality code.

Discover the timeless techniques and strategies that help you:

  • Design for minimum complexity and maximum creativity
  • Reap the benefits of collaborative development
  • Apply defensive programming techniques to reduce and flush out errors
  • Exploit opportunities to refactor—or evolve—code, and do it safely
  • Use construction practices that are right-weight for your project
  • Debug problems quickly and effectively
  • Resolve critical construction issues early and correctly
  • Build quality into the beginning, middle, and end of your project

Well, that’s it for now!

Let me know in the comments if you have read any of these or have any other must-reads for software developers!

If you have enjoyed this post, the biggest compliment you could give would be to share this with someone that you think would enjoy it!

Additionally, if you never want to miss a post, subscribe to this blog by clicking the follow button in the bottom right corner! Thanks for reading, have a great day, and never stop learning!

How to, Once and for All, Remember when to use “\” or “/” — March 11, 2015

How to, Once and for All, Remember when to use “\” or “/”

download (1)

Does anyone else have a problem with this?? This seems to pop up for me ALL THE TIME! Whether it is in a web URL, a file path on Windows computers, a file path on Mac computers, switch charters in command line, or wherever else they are used! How can I remember whether to use a forward slash or a backslash so that I do not constantly have to keep looking up the correct syntax for the situation that I am in???? Side Note: Actually, most of the time, I can’t even remember which one is called a backslash and which one is called the forward slash! I think most people have finally figured out a good way to at least get the names right (and I finally did too after remembering this trick) and that is to just picture the backslash as if it was a line that otherwise would be standing up straight, but instead, is falling BACKwards from the direction in which you read and type (therefor you can also make the mental connection that the forward slash looks like a line falling FOWARDs). Here is a picture to illustrate that:


However…. Remembering the name is usually not the biggest problem for me though. The real problem for me (and I think most people) is remembering when to use one or the other. Then I started wondering why this was so hard for me to remember when I didn’t have trouble remembering a lot of other small details about situations. Then it came to me. The reason that I could not remember this detail was because I had no CONTEXT to put it in. Or, put into other words, it just seemed like a crap shoot to me which one would be used and that there was really no rhyme or reason to it! (I thought I just had to memorize each instance when and where to use each and that there was no way around it) Boy was I wrong. Of course there was a reason and there is most definitely a method to the madness. Once I was able to put what I was trying to remember into some context, it became a breeze to always know (not remember) which slash to use. download I think an effective way to always know where and when to use each is to understand why there are forward slashes and why there are backslashes. What is the history behind them. Why couldn’t we just have picked to use one or the other?? So lets dig into that!

History of the Slashes

The forward slash (“/”) first made its way into the computer word when the operating system Unix was released. The designers of the Unix operating system decided to denote the symbol “/” to be a file path and directory separator. This happened around 1970 before Microsoft was even in the picture! Well low and behold Microsoft DOS – MS DOS 1.0 – comes to make its way onto the scene in 1981 and believe it or not, did not yet support directories at all! Most of the utilities included with DOS were written by IBM, and they used the “/” character as a “switch” character. You can still see this today in the command prompt — running the command dir /w tells the dir command to run with the wide list format option, while running the command dir c:\ tells the dir command to list the contents of drive C:\. The different types of slashes here indicate whether you’re specifying an option or a directory path. (On Unix, the – character is used instead of the / character to indicate switches.) Well MS-DOS 2.0 decided not to suck as much as MS-DOS 1.0 and introduced support for directories, but IBM wanted to keep compatibility with the original DOS utilities and other programs that expected the “/” character to be used for switches. Microsoft had already used the / character for something, so they couldn’t just re-use it. They ultimately chose the “\” character instead, as it was the most similar-looking character visually (haha thanks a lot you guys!! NOT). different-types-of-slashes-in-windows-command-prompt Windows may not be built on top of DOS anymore, but you can still see the legacy of DOS throughout Windows in the way backslashes and other features like drive letters are used for the file system.

Why Everything Else Uses Forward Slashes

This all wouldn’t really matter today, but web browsers follow the Unix convention and use / characters for web page addresses. A typical Windows user sees a forward slash when they type a web address and a backslash when they type the location of a local folder, so this can be confusing. Websites follow the Unix convention, as do other protocols like FTP. Even if you’re running a web server or FTP server on a Windows machine, they’ll use forward slashes because that’s what the protocol calls for. Other operating systems use forward slashes for the same reason — it’s the Unix convention. Linux is a Unix-like operating system, so it uses the same type of slash. Mac OS X is based on BSD, another Unix-like operating system. Other consumer operating systems like Android, Chrome OS, and Steam OS are based on Linux, so they use the same type of slash. forward-slashes-in-paths-on-linux So what to take away from all this is that EVERYTHING uses forward slashes, EXCEPT file paths in Windows (or a switch statement in a cmd prompt) only because Unix introduced the forward slash (before Windows was around) and everything went with that and Microsoft, being difficult, decided that they would confuse all of us and pick an almost identical, but different symbol, for file paths! So when in doubt use “/” unless you are accessing a file path on a Windows computer!! P.S. Finding out the WHY to something will always help you more than just trying to memorize something. Dig deep into subject matter to understand it instead of just brushing the surface and accepting it for the way it is and trying to memorize it. That’s my 2 cents!

What to Expect in a Programmer Interview — March 10, 2015

What to Expect in a Programmer Interview


The more and more I talk to developers and other software engineers, I noticed that reoccurring theme. They all wanted to know the key to doing well in technical interviews.

This is a good topic to understand because if you don’t take interviewing seriously, you will quickly find yourself having to stick with the job you have for the rest of your life or, even worse, not getting a job at all.

“But what about my all-star resume???! Wont that be enough to get me the dream programmer job that I’ve always wanted?”

And the simple answer is: NO. Not with a respectable company interested in hiring great candidates.

So what should you do? Well the first thing would be to start preparing yourself for these interviews so that you can get better at them. Few people really enjoy interviewing. A lot of times even the interviewer is uncomfortable (no one likes watching someone else sweating and shaking because they are so nervous).


I’ve been on both sides of the technical interviewing table so I want to share with you what you need to expect going into one of these so that you are not caught unprepared and blindsided.

Recently, I have been given the task of tech interviewing all of the programmers and software engineers, senior to junior level, for any open technical positions we have in our company. I have developed a list of interview questions and topics that I feel allows me to really gauge how well the candidate would preform technically. Some of these questions I have been asked myself in interviews and some of these are just some that I made up because I believe they give the candidate an OPPORTUNITY to showcase what they know.

Notice how I said opportunity.  As an interviewer I don’t want you to fail. If we have an open position for the company I want you to succeed with flying colors and then I can present you to my boss and say “I’ve found him! He is wonderful and will be great at this company! Woohoo!” (feel free to replace “him” with “her” btw. I have interviewed some great women as well.) To many candidates think that the interviewer is solely out to make them look stupid and stump them with impossible questions. That’s not the case! We just need to separate the good from the great and not so great. If you prepare with the topics and questions that I will provide below you should be well on your way to being one of those candidates classified as “great”.


Now before you go over this list and say to yourself “These are just trivia questions!” or “No one uses that anymore” or “Why would I need to know that??” or just “These are stupid questions”, remember that I’ve comprised this list from REAL-WORLD interviews that I have given and have received. Also, most of these questions will be language agnostic. I am a firm believer that what makes a great developer is not how well he understands a particular language (that is just syntax, and while it is nice, doesn’t alone make you a good developer and most importantly a great PROBLEM SOLVER). I’ve related before to the analogy of someone know multiple human languages – just because Johnny can speak mandarin fluently doesn’t make him a smart individual or problem solver in the mandarin culture.

After my interview I should be able to answer these questions about the candidate:

  • Is this someone I can see myself work with daily?
  • Is this someone that would be a good fit in the existing team?
  • Is this someone that has a desire to do a good job and learn more?
  • Is this someone who is motivated?
  • Is this someone that really knows their stuff?
  • Is this someone who would be a good fit for the position we’re filling? Or are they too advanced and would be bored or frustrated?

Alright enough already! Lets get to the questions!

I’ve broken them up into a few different topics so that I might see a candidates strengths in different areas. These areas are:

  • General technical questions
  • Development/design questions
  • Database or storage questions
  • algorithms and data structures.

Please realize that many of these questions may be geared to senior candidates and aren’t expected to be fully understood by a junior candidate – but I would like them to hopefully be familiar with some of the more advanced topics.

Technology in the hands

General Technical

  • What Source Control systems have you worked with?
  • How do you react to people criticizing your code/documents?
  • Describe, in as much detail as you think is relevant, as deeply as you can, what happens when I type “” into a browser and press “Go”.
  • How do you go about troubleshooting issues today? Give me an example.
  • What was the most difficult technical issue you’ve faced in your last project and how did you solve it?
  • What is something substantive that you’ve done to improve as a developer in your career?
  • Are you still writing code? Do you love it?
  • You’ve just been assigned to a project in a new technology how would you get started?
  • What do you do to stay abreast of the latest technologies and tools?
  • Describe a software development life cycle that you’ve managed.
  • Whose blogs or podcasts do you follow? Do you blog or podcast?
  • Tell me about some of your hobby projects that you’ve written in your off time.
  • What is the last programming book you read?
  • You have two computers, and you want to get data from one to the other. What are some ways you could do it?
  • What’s the difference between a thread and a process?


Development/Design questions

  • What is SOLID? Can you explain what each letter stands for and the reasoning behind it or why its important?
  • What is Inversion of Control? How does that relate to dependency injection?
  • Why are interfaces important? When might you use them over a base class?
  • What are some alternate ways to store data other than a relational database? Why would you do that, and what are the trade-offs?
  • What is SQL injection and how do we prevent this in our application code?
  • What’s the difference between unit test and integration test?
  • What is Refactoring? Have you used it and it is important? Name three common refactorings.
  • Name three primary attributes of object-oriented design. Describe what they mean and why they’re important.
  • What is the Repository pattern? The Factory Pattern? Why are patterns important?
  • What are some examples of anti-patterns?
  • Who are the Gang of Four? Why should you care?
  • How do the MVP, MVC, and MVVM patterns relate? When are they appropriate?
  • Explain the concept of Separation of Concerns and it’s pros and cons.
  • You have just been put in charge of a legacy code project with maintainability problems. What kind of things would you look to improve to get the project on a stable footing?
  • Show me a portfolio of all the applications you worked on, and tell me how you contributed to design them.
  • Explain the differences between stateless and stateful systems, and impacts of state on parallelism.
  • What’s the difference between asynchrony and concurrency?
  • What is Continuous Integration?  Have you used it and why is it important?
  • Are you familiar with ORM’s? What problem do they solve?


Database Questions (mostly relational DBs)

  • What kind of database technologies are you familiar with? What are the pros and cons of each?
  • What is an index?
  • What is a view?
  • Do indexes always help performance? Please explain.
  • What is the difference between a clustered index and a non-clustered index.
  • How many clustered indexes can you have on a table. Why?
  • Is it important to have primary keys and foreign keys? What are they for?
  • What is normalization? What are the pros and cons of it?
  • Which is faster: inserting one million rows of data or updating one million rows of data?
  • What steps would you take to make a query faster?
  • What is the best way to import a lot of data into a DB?
  • Tell me what your change process is for a new database change or migration.
  • How do you assess overall database health? What are the day-to-day items to keep an eye on? Can you automate any of that?
  • Do you have a Database Recovery plan? How do you test it?
  • Can you describe the difference between the different types of JOINs in SQL (INNER, LEFT and RIGHT OUTER, FULL, CROSS)
  • Can you explain what TRIGGERS are and when you might use them?


Algorithms and Data Structures

  • Implement a <basic data structure> using <some language> on <paper|whiteboard|notepad>.
  • Which sorting algorithm has the slowest rate of growth relative to its input: Selection Sort, Merge Sort, Bubble Sort, Insertion Sort…What is its worst case asymptotic Big-O time complexity? Are there any other sort algorithms that you are familiar with that can perform better on average?
  • What is a binary tree? What is it good for?
  • Are you familiar with Dijkstra’s algorithm? What is it used for?
  • What is the difference between a Stack and a Queue data structure? Can you give examples of some in real applications?
  • In terms of asymptotic time complexity, please list in order which algorithms are the slowest growing to the fastest growing:  O(n^2), O(n), O(n log n), O(log n), O(1), O(2^n)
  • Would you be able to explain how Merge-sort works?
  • If I have N sorted arrays of N length, can you implement an efficient algorithm to combine these into 1 sorted array?

Well this post got waaaaaaayyyyy longer than I anticipated…. but then again there is a lot to go over for tech interviews, which is why many people find them difficult. However, if you take time to become an expert in what you do, most of these problems will come pretty easily to you.

I will tell you from experience that most of the people I interview have the most trouble with the algorithm and data structures section. Many people don’t believe knowing the computer science aspect of programming is as important (not sure why), but these can quickly get you in trouble if you start implementing algorithms that are having quadratic O(n^2) or even, god forbid, exponential O(2^n) complexity algorithms!

Anything worth having takes some effort to achieve. So learn your craft and become an excellent programmer/software engineer to get that dream job you’ve always wanted!

I hope this list of questions, topics, and interviewing tips helps every one of you in your career path whether you are the interviewer or interviewee.

P.S. These are not a list of all the questions you will see BY FAR! These are just some of the ones I like and see more often. Cheers and happy coding!

BMPs, JPEGs, GIFs, and PNGs…Oh My! — March 5, 2015

BMPs, JPEGs, GIFs, and PNGs…Oh My!


I recently was developing a web application and needed to incorporate a company logo image on the site. When asking the marketing department to send me an image of the company’s logo so that I may put the image on the site, they responded asking me what type of image format I would like I them to send…

I have no idea! (I thought to myself)

This actually caught me off guard for a second. I was guilty of not understanding the underlining differences between all the different image formats that are out there and which would make the best use case for my situation.

Rather than sit around beating my head against the desk for not knowing my image types like I should, I quickly did some research on the topic to fill the knowledge gap in my brain (Django Reinhardt was a person I found on the web that seemed to be an expert on the topic and much of this post was only possible thanks to his articles). I knew there had to be some big differences, after all, people just don’t make up new formats to screw with us users and developers (do they????).

Well, after a few hours of reading about the differences in the different image technologies, I decided to write this post to help me remember what I discovered and to hopefully help point anyone else in the right direction if they are also unfamiliar with these formats. Well without further adieu, lets jump into it!

There are some terms that we should first familiarize ourselves with that I found in many of the articles describing these formats.

First, there are two types of compression: Lossless and Lossy.

Lossless means that the image is made smaller, but at no detriment to the quality. Lossy means the image is made (even) smaller, but at a detriment to the quality. If you saved an image in a Lossy format over and over, the image quality would get progressively worse and worse.

There are also different color depths (palettes):Indexed and Direct

With Indexed it means that the image can only store a limited number of colors (usually 256) that are chosen by the image author, with Direct it means that you can store many thousands of colors that have not been chosen by the author.

And now the image formats!! I am going to go over the main ones that you will find yourself using. I’m sure there are many more out there, but you will use one of the below in 99% of the cases.

So here we go…

BMP – Lossless / Indexed and Direct

This is an old format. It is Lossless (no image data is lost on save) but there’s also little to no compression at all, meaning saving as BMP results in VERY large file sizes. It can have palettes of both Indexed and Direct, but that’s a small consolation. The file sizes are so unnecessarily large that nobody ever really uses this format.

Good for: Nothing really. There isn’t anything BMP excels at, or isn’t done better by other formats.


GIF – Lossless / Indexed only

GIF uses lossless compression, meaning that you can save the image over and over and never lose any data. The file sizes are much smaller than BMP, because good compression is actually used, but it can only store an Indexed palette. This means that for most cases, there can only be a maximum of 256 different colors in the file. That sounds like quite a small amount, and it is.

GIF images can also be animated and have transparency.

Good for: Logos, line drawings, and other simple images that need to be small. Only really used for websites.


JPEG – Lossy / Direct

JPEGs images were designed to make detailed photographic images as small as possible by removing information that the human eye won’t notice. As a result it’s a Lossy format, and saving the same file over and over will result in more data being lost over time. It has a palette of thousands of colors and so is great for photographs, but the lossy compression means it’s bad for logos and line drawings: Not only will they look fuzzy, but such images will also have a larger file-size compared to GIFs!

Good for: Photographs. Also, gradients.


PNG-8 – Lossless / Indexed

PNG is a newer format, and PNG-8 (the indexed version of PNG) is really a good replacement for GIFs. Sadly, however, it has a few drawbacks: Firstly it cannot support animation like GIF can (well it can, but only Firefox seems to support it, unlike GIF animation which is supported by every browser). Secondly it has some support issues with older browsers like IE6. Thirdly, important software like Photoshop have very poor implementation of the format. (Damn you, Adobe!) PNG-8 can only store 256 colours, like GIFs.

Good for: The main thing that PNG-8 does better than GIFs is having support for Alpha Transparency.

PNG-8 vs GIF

Important Note: Photoshop does not support Alpha Transparency for PNG-8 files. (Damn you, Photoshop!) There are ways to convert Photoshop PNG-24 to PNG-8 files while retaining their transparency, though. One method is PNGQuant, another is to save your files with Fireworks.

PNG-24 – Lossless / Direct

PNG-24 is a great format that combines Lossless encoding with Direct color (thousands of colors, just like JPEG). It’s very much like BMP in that regard, except that PNG actually compresses images, so it results in much smaller files. Unfortunately PNG-24 files will still be much bigger than JPEGs, GIFs and PNG-8s, so you still need to consider if you really want to use one.

Even though PNG-24s allow thousands of colors while having compression, they are not intended to replace JPEG images. A photograph saved as a PNG-24 will likely be at least 5 times larger than a equivalent JPEG image, with very little improvement in visible quality. (Of course, this may be a desirable outcome if you’re not concerned about file size, and want to get the best quality image you can.)

Just like PNG-8, PNG-24 supports alpha-transparency, too.


Who knew that there was so much in choosing the correct image format technology to use???? (Not me!)

I hope that helps!

P.S. For those curious, I replied to the marketing team (several hours later) with “I will have it in a GIF format please”