Software Engineer Job Description

There was an article I read in the news lately about the top 7 careers in Utah. Number three in the list was a software developer or software engineer. The terms have slightly different meaning, but can be interchanged quite frequently. Quite often I have either been asked what to include in a my company’s software engineer job description when we are looking to hire new engineers, or I have been looking for jobs and had to sift through tons of different qualification requirements. It seems every company has a different idea of what is a software engineer in their job description. Although it is perfectly ok to have specific requirements, we should broaden the scope a little bit. If an engineer is good at problem solving, debugging, and looking through other’s then the engineer should be considered for a position even if he or she is not familiar with the technologies that make up the specific company’s stack.

GOOD software engineer description

• CAN CODE: Obviously you need someone who can code. The best way is to have a person either code or sudo code during an interview. Have the potential candidate go to a white board and solve some problem of your choice. Some common examples are to have the engineer code a binary search or code a method to detect a palindrome.
• UNDERSTAND DATA STRUCTURES: Knowing different data structures like trees, lists, sets, and maps is essential. Every type of data structure has a specific purpose. These are just more tools inside an engineers tool belt.
• KNOW DESIGN PATTERNS: The world of software has lots complexities in it. A software engineer should know several different design patterns. These patterns are like tools in an engineers tool belt. Each tool should do one job and do it really well. Some examples of design patterns are understanding singletons, command patterns, rest, or dependency injection. These are independent of any language.
• DEBUG CODE: This is an absolute must in any software engineer. Using tools such as debug mode in an IDE or how to use programs like gdb are essential. Code will always have bugs, and being able find, troubleshoot, and fix bugs is essential. You could always present some code to the engineer with a bug and ask him or her to figure out what is wrong and give a possible solution.
• SOLVE PROBLEMS: Any features that a company or customers need often include complex problem solving. For example how to persist data based on what is need more, writing or reading? What is the best solution to the problem?
• UNDERSTAND COMPLEXITY: Knowing every algorithm and its big O complexity is overrated. More important is being able to derive big O complexity. Have the engineer determine what the big O complexity of some provided method.
• DESIGN STRUCTURES: If your stack uses OOP (Object Oriented Programming), functional (i.e. javascript or c), or embedded paradigms then the engineer should have some familiarity with them. A kernel developer, for example, needs to understand good functional programming designs more than object oriented designs.
• WHAT DON’T I KNOW: Most software engineers do not know the answers to every question. Being able to know what to search for on google is important. Example: If you are in angular land you need to know how to speak the angular language. Searching should use things like directives or scope.
• STAYS MODERN: Software is a fast moving field. If an engineer does not stay current he or she falls behind fast. A prime example is knowing only perl or php. Most software stacks have moved towards some rest server like java or node and a frontend in angular. While there are so many technologies out there knowing specifics can be hard, but an engineer should be familiar enough with what various technologies to know if they will be a solution to specific problems that arise.
• KNOWS MATH: Knowing how to implement a mathematical function – such as a simple Riemann sum – is what separates a junior or entry level position from a senior or architect level position. You could always provide a mathematical equation and have the engineer give sudo code of how to translate the idea into code.

BAD software engineer description

• SPECIFIC LANGUAGE: I have had interviews that ask very specific questions to a programming language. They reference obscure aspects of a language that nobody will need on a regular basis. Being able to google an answer is more important than knowing specifics.
• SPECIFIC APPLICATIONS: While this should be determined on a case by case basis, having requirements like knowing specific applications should generally be avoided. Example: requiring a software developer to know protractor for end to end testing. This still uses selenium under the hood and has all the same selenium problems that any other end to end testing framework will have.
• LIMITING TO DEGREES: Having a degree is always beneficial. Especially from colleges or universities that have abet accreditations. I have mixed feelings on this subject. Some self taught engineers are so thirsty to know in depth how to program, but some learn just enough to get by and have gaps in their knowledge.
• TAKE HOME CODE TESTS: These are terrible because the user can easily have someone else code the solution. If you need to give them a take home test to assess the engineer’s ability to program, then you should add bugs to the code and have the engineer debug the code in real time during an interview.
• NOT ALLOWING SEARCHING: There have been interviews I have had where I have been required to take some test without being able to use google. Being able to know what to search for in order to solve a problem is 100% essential to a good engineer.

Benefits

The number of jobs that require software to be made is only going to increase. The number of people with mobile computing platforms (iphones or android phones) is very prevalent. A company needs to not only have a competitive salary, but have other benefits or perks to attract top talent. Some companies provide 20 days paid vacation in the first year along with catered meals and great health benefits. Having good benefits will give the company a bigger pool of candidates to select.

Conclusion

Hopefully this helps define a good software engineer job description. These are things a company should look for and not look for in potential software engineering candidates.