coder, gamer, parent
So it’s that time of the year again. Hiring season. The company I work for is looking for a (full stack) senior software engineer. As Lead / Principle Developer I will be interviewing candidates hoping to get their foot in the door, most of which fail the 5 minute mark.
Before I continue I should define what I term a senior software engineer and why most candidates who apply don’t exactly match that description.
The top rated answer on Stack Exchange sums it up nicely: When you should call yourself a senior developer
However that’s not quite what I’m looking for in a senior developer either. That is however the foundation of a senior software developer, or the starting point.
Most people applying for senior positions are hoping to progress from mid level but lack an understanding of the requirements of the role or position. Alternatively they’re senior in age and experience, however have never progressed past the coding conventions of 20 years ago. God classes, copy and paste everything, and testing code in production.
Here’s what I’m looking for when I’m interviewing candidates, and why.
Dealing with legacy software is almost always filled with technical debt, compromising code, poor architecture, dirty hacks, bad design, code smells the list goes on. This requires strategies to not only work effectively with legacy code but to identify what’s broken in the existing architecture , and design solutions to correct it. Continuing to slap mud into a big ball is not a solution a senior developer should make.
When asked the question “what’s a design pattern that you know or have used” most candidates cite “singleton pattern”, and I shudder. Yes it has it’s place however it’s also considered an anti-pattern and can sometimes do more harm than good. Refactored code will often contain some of the common design patterns and could take some time to get your head around them if you’re unfamiliar. Let alone be expected to improve upon them. The primary goal of touching any legacy software is to leave it in a better state than when we started. I’m not going to list the design patterns that you’ll need, I’ve already written articles on this topic already.
A follow-on from the first point, clean code and architecture is a requirement for writing maintainable and easily testable and understood code. Any software project should strive to keep their code base maintainable whilst reducing any pain points when needing to introduce change to the architecture or design. As as aside here I’d add passing knowledge of Domain Driven Design, the concepts of bounding contexts and having a domain is more of an implementation detail of how to keep a clean architecture but is one of the tools that I use to separate architectural concerns along with clean architecture.
I personally don’t follow the strict Kata that Bob Martin evangelizes, however I agree wholeheartedly before you create a pull request, you should have a Unit / Integration test that proves the code you’ve just requested to be merged. One of the biggest problems often with legacy software is a lack of unit or integration tests, requiring all developers to have unit and integration tests around their software is one way that I can slowly chip away at the lack of code coverage.
Preferring “pure” functions over writing procedures gives us an opportunity to lessen the chances of introducing defects into what is mostly and imperative code base. John Carmack the co-founder of id-software and lead programmer has this to say about the subject. Does that mean that my code bases read like F# or Haskell or some variant of Lisp? No.. but where appropriate you will see functions declared so as to minimize global state and unexpected side-effects.
Most popular O.R.M. tools are not thread safe. Understanding thread safety and how this will affect the behavior of the software application and architecture is an important ability. This may be somewhat subjective, not all developers have experience working with Async or Multi-threading, however most will have some experience even if it’s via MVVM view models running code on the background threads to avoid locking the UI on WPF or Winforms apps. Performance matters, being able to write safe non-blocking performant code is often as important as knowing operational complexity of an algorithm or data structure, and how to debug and write tests for such code is just as important.
The lists above is far from comprehensive, these are the key items that I look for in assessing the suitability of a candidate for a senior software engineer role. For me a senior engineer should be capable of handling end to end software development. Developing appropriate solutions that fit in with the overall architecture goals of the applications. Write well maintained, clean, readable, easily understood, tested, testable code. Writing code that performs, is scalable and is able to pass on knowledge to mid level and junior developers.
I have close to 20 years of experience writing software, I have first hand experience of what happens when you DON’T do any of the above. Hard earned experience forces us to look for answers to problems of the past to improve ourselves, recognize our mistakes, and iterate towards better outcomes. The items I’ve listed above are key skills that I couldn’t live without, how about you?
The industry today is in such a better shape than it was 20 years ago, I look forward to seeing how the industry is going to evolve in the future.
You should keep a copy of useful information on your own blog, and not just keep a link to the original. This advice may seem to violate netiquette or social norms, but there’s a good reason to do it. A blog or link to stackoverflow isn’t permanent, a personal blog or site can be taken down or moved and your information is lost. This goes double for rarely used or niche technical info and blogs.
I’ve had this happen to me at least twice in the last 2 years, bookmarked a useful blog with the intention to come back later and finish the project and … it’s gone. Google search for similar information comes up with nothing. The same goes for stackoverflow, the links are supposed to be unique to help people find information. However they do prune the data and links are not guaranteed to be always present, they can be deleted or removed. Blogs can be moved or the original author decides to stop paying for their website or whatever \_()_/
If you find something important, grab a copy of the original and store it somewhere. Do yourself and the world the favor, write your own version publish it online and reference the original author as it’s only the polite thing to do. At least then you’ll have a copy for as long as you need it.
In: Essays
9 Jun 2018I’ve been a Team Lead, put in charge of projects with developers several times in the past few years. I’ve found myself in the position again after accepting a recent promotion. A lot of developers try to avoid the promotion to team lead because it involves a lot soft skills that are difficult to obtain or learn on the job.
Most software development teams that I’ve been a part of were are structured in such a way as to optimize a developers time, so that they can concentrate on tasks that provide the most business value (coding). This provides less time learning the necessary soft skills in order to be an effective team lead.
This had me thinking, what makes a good Team lead?
That’s quite subjective, and going to have a different answer for every company. I’ve personally found the following skills essential
Being able to communicate effectively with people in a timely fashion. For developers this means that you might need to explain something in deep technical detail or write and design a process flow diagram. At the same time communicate with upper management on the progress of the 5 projects that your team is currently working on and provide estimations and projections on completion dates.
Sometimes this may also require you to “manage up”. This might be a polite email prompt to a stakeholder or client that you’re waiting for sign off on a particular design decision. Or a friendly reminder to your boss that something needs their input, they’re often busy and sometimes a little reminder is required. It’s best not to wait for manager to chase you to inquire about the status of projects your team are working on.
SCRUM and Agile are great tools in order to help provide transparency to the business, and in my opinion is one of the core skill of a team lead.
One of the most important features of Agile that most companies overlook is that you should only have 1 backlog, and that backlog should be groomed in such a way as to prioritize the features that provide the most business value at any given time.
Having a separate backlog per project simply doesn’t work, what will happen is that you will get 1 or 2 developers dedicated to a project and you attempt to work on projects in parallel with dedicated resources. So you could be wasting time working on low value project work when they should really drop that $5 widget spinner and work on finishing that 500K feature for your most valued client.
1 backlog, 1 Team, 1 list of items that always provides the most business value at any given point in time.
Have a sprint planning wall.
It seems redundant at first blush but I personally find it hard to see large numbers of items in Jira. Walls don’t have that limitation, and also have added convenience of being able to be glanced and consulted by passing stakeholders and development managers who may not be familiar with Jira, but they can consult a wall. Developers can consult the board during daily standups and move sticky notes when they’ve completed a task.
It’s also convenient for reporting and tracking the status of multiple projects/features at the same time at a single glance. It’s not a replacement for Jira, but an additional tool to help visual and manage multiple projects.
Developers may look to you for guid