30 Skills to Master to Become a Senior Software Engineer
1. 30 Skills to Master to Become a
Senior Software Engineer
Dr. Sean Coates
February 6, 2016
2. About Me
• CTO at CircleBack Lending - Boca Raton, FL
3. Why I Care
• hired 15 PHP developers in the past 18 months
• reviewed hundreds of candidates
• 95% of candidates simply do not measure up
• really wish more people embraced these skills
• we always need more senior software engineers
4. Why You Should Care
• Senior Software Engineers command higher salaries
• software development done the right way makes for
more reliable applications that are easier to expand
• well-rounded individuals are more likely to be tasked
with mentoring and leading others, to spread the
• a lot less time wasted on technical debt
5. Fair Warning!
• this is a highly opinionated presentation
• I favor open source and PHP related technologies,
but there are certainly other paths to success
• your mileage may vary
• going to cover a lot of ground quickly - there is a
link to the slides at the end
6. If You Want to Keep Score
There are 30 skills, if you want to score yourself, give
your self points on each slide based on which
solution matches your practice.
• 0 points for poor
• 3 points for fair
• 7 points for good
• 10 points for excellent answers
7. 1. A Server-Side Programming Language
In the early days of the web, this
might have been all you needed.
Also, we’re going to assume web
applications here - things are
diﬀerent for other applications.
Other types of applications include
mobile apps, video game
development, data science
applications, embedded / device
development. These will require
diﬀerent technologies and tools.
8. 1. A Server-Side Programming Language
Poor: C, Fortran, COBOL,
Fair: Perl, Node.js, Scala
Good: Ruby, Java,
Excellent: PHP, of course.
9. 2. Database Technology
The database is the foundation
of your application and can be
the source of many problems if
not implemented correctly.
Not only is it the retention of all
of your data, it also deﬁnes how
you are modeling your business
objects. Do it wrong, and you
can have all kinds of diﬃculties.
10. 2. Database Technology
Poor: Just using ﬂat ﬁles.
Fair: Mongo or some other NoSQL store only. Or, using a
commercial database product.
Good: SQL on MySQL or PostgreSQL
Excellent: Experience with an RDBMS (MySQL,
PostgreSQL, MariaDB Aurora), a columnar store (Amazon
Redshift), and a key/value store (Mongo, Redis, others).
Great with several DBs.
11. 3. SQL and Data Modeling
Improper and ineﬃcient use
of SQL is the most common
source of performance
problems in applications.
Data modeling covers
concepts like normalization,
It also communicates your
understanding of the data.
12. 3. SQL and Data Modeling
Poor: Relies on ORMs to perform database queries.
Fair: Writes basic SQL. Works with a DBA to create tables.
Good: Good with complex queries. Understands
normalization. Has a style guide.
Excellent: Can explain a query plan. Handle extremely
complex queries. Strong skills with normalization and
modeling. Follows a style guide.
13. 4. HTML
Used to describe web
documents, HTML5 has added
new features including
multimedia elements and
support for scalable vector
graphics and mathematical
14. 4. HTML
Poor: Relies on word processors or web publisher
tools to create web pages.
Fair: Can write documents in raw HTML.
Good: Uses some of the new multimedia features in
Excellent: Full understanding of HTML5. Developed
replacements for Flash components. Uses MathML.
15. 5. CSS
Cascading Style Sheets
allow developers to control
the styling of web elements
independently of the HTML
source code. CSS3 adds
new features giving web
designers more control.
Now, Sass and other tools
are available to make writing
16. 5. CSS
Poor: Limited or no use of CSS styling.
Fair: Limited use of CSS ﬁles.
Good: Using Bootstrap and templates. Using other
CSS tools like Less.
Excellent: Extending past Bootstrap using Sass, highly
customized styles reﬂecting your corporate identity.
This browser-side language has
been used to push logic down to
the client, enabling for more
Using techniques like AJAX it is
possible to create single-page
applications which are popular in
Poor: Spaghetti code that causes problems for everyone who
Fair: Simple animations and rendering.
Good: Can perform basic AJAX functions, making interactive
Excellent: Excellent use of AJAX, ECMAScript, JSON, and
related tools to create client-side programs that run in the
browser. Follows OOP techniques and pursues the same level of
code quality as seen on the server.
19. 7. A Client-Side Framework
While most people at this
point are programming with
jQuery, there have been
several frameworks and
libraries in recent years that
greatly advance the state of
the art. And while it may be
premature to pick a winner
at this point, AngularJS has
the mindshare currently.
20. 7. A Client-Side Framework
Poor: Limited or no use of jQuery or other tools.
Fair: Moderate use of jQuery only. May also use older
libraries like Ext JS and Prototype.
Good: Strong use of jQuery with one of the other
frameworks (Backbone, React, Vue)
Excellent: Robust use of AngularJS and jQuery,
libraries like D3.js.
22. 8. Gulp
Gulp is a toolset that automates
part of your workﬂow. It covers
many areas including CSS
preprocessing, CSS and JS
miniﬁcation, running unit tests,
refreshing your browser when
saved ﬁles change, and many
23. 8. Gulp
Poor: You’re doing these things mostly by hand.
Fair: A collection of random scripts. Apache Ant, YUI
Good: Using an alternative instead, or just using Gulp for a
couple of things. Grunt, Broccoli, Brunch, Mimosa are
among the many options.
Excellent: Making use of Gulp to automate several parts of
24. 9. Node.js
the development of Node.js. We generally prefer PHP
for server-side development, but there are a lot of
great tools (Gulp included) that are built using Node,
so knowledge of Node has become required.
25. 9. Node.js
Poor: No experience with Node.
Fair: At least one application using Node.
Good: Using Node to serve up pages instead of PHP.
Excellent: Automating several server-side operations
and development workﬂows using Node and tools
built on Node.
26. 10. Virtual Machines
With virtual machines, you can
create a Linux environment
running on your laptop that
resembles your production
environment more closely than
just running applications
natively on OS X.
With Vagrant, provisioning
these virtual machines
becomes easier, often pre-
loaded with a full suite of
27. 10. Virtual Machines
Poor: Still running on dedicated servers.
Fair: Passive experience with VMs, such as using
Good: Using Vagrant to load and develop on Homestead.
Excellent: Creating your own VMs and sharing them with
your team, to save the work of installing all the various
libraries and tools.
28. 11. SSH
OpenSSH is the most popular
implementation of SSH. SSH is a
key tool used for accessing
systems remotely, copying data,
and creating secure pipelines
Working with SSH requires an
understanding of public-key
29. 11. SSH
Poor: the 80s called they want their telnet and ftp
Fair: Just ssh.
Good: Using ssh and scp.
Excellent: Proper use of public key encryption, key
sizes, ssh, tunneling, and secure copy.
30. 12. Version Control
Being able to maintain
multiple concurrent versions
of the software is crucial for
While git is widely used by
most, not everyone uses the
advanced features or follows
the gitﬂow method.
31. 12. Version Control
Poor: Ancient systems like cvs, or often no use of
version control at all.
Fair: Instead of git, uses svn, Mercurial, Perforce, or TFS.
Good: Using git, typically with feature branches.
Excellent: Using git with
gitﬂow, with separate
develop, master, feature,
release, and hotﬁx
32. 13. A Server-Side Framework
Laravel has become the most
popular MVC framework,
bringing not only a great
collection of best practices and
supportive ecosystem, it also
incorporates a great collection
of tools and components.
Examine Sitepoint’s 2015 survey
of PHP frameworks to see
Laravel ahead of all others for
use at work and in personal
33. 13. A Server-Side Framework
Poor: A custom built, “in-house” framework. Or non-
MVC frameworks like Drupal, Wordpress.
Fair: Zend Framework 2, CodeIgniter, Phalcon, other
open source MVC frameworks.
Good: Latest version of Symfony, Yii, or CakePHP.
Also Rails (Ruby), Django (Python), Play (Java).
Excellent: Using Laravel and all of its components.
Watching Laracasts, following Laravel blogs.
34. 14. An Object-Relational Mapper
With the rise of the MVC pattern and the Repository
pattern, ORM tools have been created to make life
easier and keep developers from writing the same
code in every application.
Most implementations follow the Active Record or the
Data Mapper pattern.
35. 14. An Object-Relational Mapper
Poor: A custom built ORM, or worse, not using an
ORM at all.
Fair: Propel. Also, other ORMs in other frameworks.
Good: Doctrine - A Data Mapper implementation used
by many other frameworks.
Excellent: Eloquent - Laravel’s Active Record
36. 15. Database Seeding and Migrations
Database seeders are scripts that set initial data in
tables, or sometimes deﬁne the entire contents of a
reference data table.
Migrations are scripts used to create and alter
database tables as part of a software change.
These scripts ensure the database has the correct
data and schema across the various versions.
37. 15. Database Seeding and Migrations
Poor: Database changes performed by hand.
Fair: Migration scripts are in use.
Good: Seeders and migrations are in use.
Excellent: Seeders and migrations are always used,
and maintained in version control. A key part of using
Laravel, for example.
38. 16. View Templates
In the early days PHP itself
served the purpose of view
templates, but we’ve come a
long way since then and there
are very powerful tools available
now. These keep application
logic completely separated from
presentation logic, and allow
front-end developers to focus
on the view.
39. 16. View Templates
Poor: In-house custom engine, or none at all.
Fair: Smarty - was good in its day but we have much
better options now.
Good: Twig, which has a great following.
Excellent: Blade. That means you’re using Laravel.
40. 17. Security
Any real business has to be
acutely concerned with
security. Web applications have
a long history of being subject
to hacks due to weakness in
Hackers, script-kiddies, DDOS
attacks, corporate espionage,
negligence, and criminals
provide an ever-growing pool of
threats that we must be vigilant
41. 17. Security
Poor: Having a purely reactive approach.
Fair: Occasional security scans.
Good: Adopting some security techniques and scans,
often in response to an audit.
Excellent: Guided by a
CISO, following OWASP,
building a security maturity
model, making security a
part of every code review.
42. 18. Creating APIs
Most systems will end up talking to other systems.
Sometimes it’s a simple matter of breaking up the
monolith, and sometimes it’s relying on 3rd-party
services outside your company in order to more
eﬃciently perform your business functions.
The connections between these systems need to be
developed in a clear, predictable, manageable way
that is easy to improve and expand.
43. 18. Creating APIs
Poor: Custom-built XML-based APIs, trading
messages via csv ﬁles or ﬁxed-length records.
Fair: Good old SOAP. APIs are documented but dated.
Good: REST with XML, but some of the above is
Excellent: Sending JSON data via REST commands,
properly versioned, documented, and authenticated.
Asynchronous messages land in queues. Use industry
standards where available.
44. 19. Composer
As applications increase in
size, the number of packages
included grows dramatically.
Using a tool like Composer
allows you to manage your
libraries and dependencies
45. 19. Composer
Poor: Including libraries and automatically asking for
the latest, untested version. Every build is an adventure!
Fair: Including hundreds of libraries and packages, not
sure if they are all still in use.
Good: Using Node’s npm, or Ruby’s bundler. Depending
on outside repositories to build.
Excellent: All of your libraries are managed by
Composer, and local copies of properly vetted versions
of libraries are kept.
46. 20. Packages
Don’t reinvent the wheel.
Don’t spend countless
resources developing some
common functionality that
can be had much more
easily by using a package or
47. 20. Packages
Poor: Custom-build all the things.
Fair: Using old, dated packages. Struggle with
Good: Using the latest packages, even some obscure
bleeding edge ones.
Excellent: Recognize which packages and libraries to
use, which versions are best, and stick to those
which are popular and widely used.
48. 21. Creating Dummy Data
When creating large amounts
of test data for your test
suites, you want that data to
look realistic. At the same
time, using production data is
considered to be too risky.
Fortunately, there are tools
available to help. Faker is
among the best of these.
49. 21. Creating Dummy Data
Poor: Not creating any test data. Or using production
data and exposing customer private information to a
Fair: Copying production data and then writing scripts
to scrub out the private information.
Good: Using your own scripts to generate test data.
Excellent: Robust use of Faker to generate test data.
50. 22. Unit Testing
One of the biggest indicators
that separates the senior
software engineers from the
rest of the pack is the use of
unit testing and test driven
When people say they don’t
“have the time” to write unit
tests, they always spend ten
times as long ﬁxing bugs and
battling technical debt.
51. 22. Unit Testing
Poor: Not writing tests. Thinking you don’t have the
time to write tests.
Fair: Writing some phpunit tests after the fact, aiming
for better code coverage.
Good: Doing TDD with phpunit or phpspec, covering
happy path and some failure cases.
Excellent: Doing BDD with Behat and TDD with
phpspec. Covering all your edge cases.
52. 23. IDE
Many old-school developers
often rely solely on a text
editor to write their code.
Others use advanced editors
with nice plugins and
integrations. An integrated
provides much more
functionality and power to the
53. 23. IDE
Poor: Simply using a text editor.
Fair: Sublime Text or vim power-user with lots of
plugins and integrations.
Good: Using other IDEs like Eclipse.
Excellent: Using PhpStorm with XDebug and taking
full advantage of its features.
54. 24. NoSQL
Sometimes known as document
stores or key-value stores, NoSQL
databases like MongoDB,
CouchDB, Redis, Memcached,
Dynamo, Cassandra and others
provide a simple way for storing
unstructured data. Also used in
situations where database
schema changes rapidly.
While the best product depends
on the application, there are
certain guidelines in the use of
55. 24. NoSQL
Poor: Storing data in text ﬁles.
Fair: Storing data in obscure proprietary databases
(Access) or custom-built databases. Or using a NoSQL
database for everything.
Good: Using a NoSQL database for storing session data
and a couple other common applications.
Excellent: Using appropriate NoSQL databases for certain
applications involving unstructured data or data with single
keys. Using RDBMS for highly structured, relational data,
and columnar stores for data warehouse applications.
56. 25. Automated Deployment
The process of assembling
software, running tests,
integrating libraries, compiling
code, and building packages
can be complex and prone to
error. Thus it is wise to apply
as much automation as
possible to these processes.
57. 25. Automated Deployment
Poor: No automation, processes handled manually.
Fair: A random collection of custom scripts.
Good: Some use of Jenkins, or using other CI tools
like Bamboo or Travis.
Excellent: Using Jenkins with the Jenkins Best
58. 26. Business Analysis
This is the art of identifying
business needs and
Typical work products
include storyboards, use
cases, UML diagrams,
ﬂowcharts, wireframes, and
59. 26. Business Analysis
Poor: You receive and react to random requests from the
business all the time.
Fair: You’re working with excessive business
requirements documents ﬁlled with outdated information.
Good: You can develop robust functional speciﬁcations
and have a strong understanding of the business.
Excellent: Not only can you write excellent speciﬁcations,
you also have a deep understanding of the business and
help design new processes and systems.
60. 27. Project Management
When projects grow in size
and require the eﬀorts of
several individuals or teams, it
becomes necessary to
manage the project’s
dependencies and resource
61. 27. Project Management
Poor: No planning or coordination.
Fair: Proactive eﬀorts are made, planning occurs.
Good: You’re using some project management tools.
Plans are documented and tracked.
Excellent: You can coordinate the eﬀorts of several
teams while maintaining the Agile principles, making
strong use of tools that integrate with the ticket
tracking system and other tools.
62. 28. Ticketing System
With a good issue tracking
system, you not only
manage the present
requirements, you also
provide historical statistics
and reference material.
63. 28. Ticketing System
Poor: Physical tickets like post-its or 3x5 cards.
Fair: Older open-source tools like Mantis and Bugzilla.
Other commercial products lacking in features.
Good: Other professional tools such as Rally, Pivotal
Tracker, Microsoft TFS. A healthy implementation of
Redmine also works.
Excellent: Using JIRA to track all issues, bugs, projects,
and desired features. Customizing JIRA to model your
64. 29. Teamwork
A highly eﬀective team can
accomplish much more than
individuals acting separately.
Strong teams also learn faster
and lower defect rates.
65. 29. Teamwork
Poor: A cowboy culture of rock stars, coding ninjas,
Fair: A co-located team working on the same project.
Good: Peer-level code reviews using pull requests. A
Excellent: Using pair programming regularly. Team in
constant communication via Slack or HipChat.
66. 30. Patterns of Enterprise Engineering
In software development,
common problems reoccur
regularly. This leads to
general, re-usable solutions.
By learning these patterns,
we gain a common language
for describing these
situations and, at a high
level, their solutions.
67. 30. Patterns of Enterprise Engineering
Poor: Ignorance of patterns leading to random
solutions each time.
Fair: Occasional use of a few patterns.
Good: A software architect on the team understands
several common patterns and provides guidance.
Excellent: Everyone on the team understands the
patterns widely used in solving the company’s
software problems. Pattern solutions used
appropriately (don’t overdo it).
68. So, that’s all you need to know.
Now you’re ready to be a senior software engineer!
You got 300 points, right?