It has been a while since I wrote a blog posts directed at newly minted Computer Science Majors. In fact, the last time I wrote one of these articles was in 2014. So I’m going to give all of you shiny-new Computer Scientists a leg-up in the working world by telling you some inside information about what companies need from you. If you read through my previous blog post (click here) and read through this post, you’ll be ahead of the pack when you submit your resume for that first career starting job.
Purpose of this Post
First of all, I’m going to tell you my motivation for creating these posts. In other words: “What’s in it for Frank.” I’ve been programming since 1978 and I’ve been employed as a software engineer/developer since 1994. One of my tasks as a seasoned developer is to review submitted programming tests, create programming tests, read resumes, submit recommendations, interview potential developers, etc. By examining the code submitted by a programming test, I can tell a lot about the person applying for a job. I can tell how sophisticated they are. I can tell if they are just faking it (i.e. they just Googled results, made it work and don’t really understand what they are doing). I can tell if the person is interested in the job or not. One of the trends that I see is that there is a large gap between what is taught in colleges and what is needed by a company. That gap has been increasing for years. I would like to close the gap, but it’s a monstrous job. So YOU, the person reading this blog that really wants a good job, must do a little bit of your own leg-work. Do I have your attention? Then read on…
What YOU Need to Do
First, go to my previous blog post on this subject and take notes on the following sections:
For those who are still in school and will not graduate for a few more semesters, start doing this now:
- Programming competitions
- Resume Workshops
- Did I mention: Web Presence?
You’ll need to decide which track you’re going to follow and try to gain deep knowledge in that area. Don’t go out and learn a hundred different frameworks, twenty databases and two dozen in-vogue languages. Stick to something that is in demand and narrow your expertise to a level that you can gain useful knowledge. Ultimately you’ll need to understand a subject well enough to make something work. You’re not going to be an expert, that takes years of practice and a few failures. If you can learn a subject well enough to speak about it, then you’re light-years ahead of the average newly minted BS-degree.
Now it’s time for the specifics. You need to decide if you’re going to be a Unix person or a .Net person. I’ve done both and you can cross-over. It’s not easy to cross-over, but I’m proof that it can happen. If you survive and somehow end up programming as long as I have, then you’ll have experience with both. Your experience will not be even between the two sides. It be weighted toward one end or the other. In my case, my experience is weighted toward .Net because that is the technology that I have been working on more recently.
If you’re in the Unix track, I’m probably not the subject expert on which technologies you need to follow. Python, Ruby, which frameworks, unit testing, you’ll need to read up and figure out what is in demand. I would scan job sites such as Glass Door, Indeed, LinkedIn, Stack Exchange or any other job sites just to see what is in demand. Look for entry level software developer positions. Ignore the pay or what they are required to do and just take a quick tally of how many companies are asking for Python, PHP, Ruby, etc. Then focus on some of those.
If you’re in the .Net track, I can tell you exactly what you need to get a great paying job. First, you’re going to need to learn C#. That is THE language of .Net. Don’t let anybody tell you otherwise. Your college taught you Java? No problem, you’re language knowledge is already 99% there. Go to Microsoft’s website and download the free version of Visual Studio (the community version) and install it. Next, you’ll need a database and that is going to be MS SQL Server. Don’t bother with MS Access. There is a free version of SQL as well. In fact the developer version is fully functional, but you probably don’t need to download and install that. When you install Visual Studio the Express version of SQL is normally installed with it. You can gain real database knowledge from that version.
Follow this list:
- Install Visual Studio Community.
- Check for a pre-installed version of MS SQL Server Express.
- Go out and sign up for a GitHub account. Go ahead, I’ll wait (click here).
- Download and install SourceTree (click here).
Now you have the minimum tools to build your knowledge. Here’s a list of what you need to learn, using those tools:
- How to program in C# using a simple console application.
- How to create simple unit tests.
- Create an MVC website, starting with the template site.
- How to create tables in MS SQL Server.
- How to insert, delete, update and select data in MS SQL Server.
- How to create POCOs, fluent mappings and a database context in C#.
- How to troubleshoot a website or API (learn some basic IIS knowledge).
- How to create a repository on GitHub.
- How to check-in your code to GitHub using SourceTree.
That would pretty much do it. The list above will take about a month of easy work or maybe a hard-driven weekend. If you can perform these tasks and talk intelligently about them, you’ll have the ability to walk into a job. In order to seal-the-deal, you’ll have to make sure this information is correctly presented on your resume. So how should you do that?
First, make sure you polish your projects and remove any commented code, remove any unused or dead-code. If there are tricky areas, put in some comments. Make sure you update your “Read-Me” file on GitHub for each of your projects. Put your GitHub URL near the top of your resume. If I see a programmer with a URL to a GitHub account, that programmer has already earned some points in my informal scale of who gets the job. I usually stop reading the resume and go right to the GitHub account and browse their software. If you work on a project for some time, you can check-in your changes as you progress. This is nice for me to look at, because I can see how much effort you are putting into your software. If I check the history and I see the first check-in was just a blank solution followed by several check-ins that show the code being refactored and re-worked into a final project, I’m going to be impressed. That tells me that you’re conscious enough to know to get your code checked-in and protected from loss immediately. Don’t wait for the final release. Building software is a lot like producing sausage. The process is messy, but the final product is good (assuming you like sausage).
If you really want to impress me and by extension, any seasoned programmer, create a technical blog. Your blog can be somewhat informal, but you need to make sure you express your knowledge of the subject. A blog can be used as a tool to secure a job. It doesn’t have to get a million hits a day to be successful. In fact, if your blog only receives hits from companies that are reading your resume, it’s a success. You see, the problem with the resume is that it doesn’t allow me to into your head. It’s just a sheet of paper (or more if you have a job history) with the bare minimum information on it. It’s usually just to get you past the HR department. In the “olden” days, when resumes were mailed with a cover letter, the rule was one page. Managers would not have time to read novels, so they wanted the potential employee to narrow down their knowledge to one page. Sort of a summary of who you are in the working world. This piece of paper is compared against a dozen or hundreds of other single-page resumes to determine which hand-full of people would be called in to be interviewed. Interviews take a lot of physical time, so the resume reading needs to be quick. That has changed over the years and the rules don’t apply to the software industry as a whole. Even though technical resumes can go on for two or more pages, the one-page resume still applies for new graduates. If you are sending in a resume that I might pick up and read, I don’t want to see that you worked at a Walmart check-out counter for three years, followed by a gig at the car wash. If you had an intern job at a tech company where you got some hands-on programming experience, I want to see that. If you got an intern with Google filing their paperwork, I don’t care.
Back to the blog. What would I blog about if I wanted to impress a seasoned programmer? Just blog about your experience with the projects you are working on. It can be as simple as “My First MVC Project”, with a diary format like this:
Day 1, I created a template MVC project and started digging around. Next I modified some text in the “View” to see what would happen. Then I started experimenting with the ViewBag object. That’s an interesting little object. It allowed me to pass data between the controller and the view.
And so on…
Show that you did some research on the subject. Expand your knowledge by adding a feature to your application. Minor features like, search, column sort, page indexing are important. It demonstrates that you can take an existing program and extend it to do more. When you enter the working world, 99% of what you will create will be a feature added to code you never wrote. If your blog demonstrates that you can extend existing code, even code you wrote yourself, I’ll be impressed.
Taking the Test
Somewhere down the line, you’re going to generate some interest. There will be a company out there that will want to start the process and the next step is the test. Most companies require a programming test. At my point in my career the programming test is just an annoyance. Let’s call it a formality. As a new and inexperienced programmer, the test is a must. It will be used to determine if you’re worth someone’s time to interview. Now I’ve taken many programming tests and I’ve been involved in designing and testing many different types of programming tests. The first thing you need to realize is that different companies have different ideas about what to test. If it was up to me, I would want to test your problem solving skills. Unfortunately, it’s difficult to test for that skill without forcing you to take some sort of test that may ask for your knowledge in a subject that you don’t have. I’ve seen tests that allow the potential hire to use any language they want. I’ve also seen tests that give very gray specifics and are rated according to how creative the solution is. So here are some pointers for passing the test:
- If it’s a timed test, try to educate yourself on the subjects you know will on the tests before it starts.
- If it’s not a timed test, spend extra time on it. Make it look like you spent some time to get it right.
- Keep your code clean.
- No “TODO” comments.
- No commented code or dead-code.
- Don’t leave code that is not used (another description for dead-code).
- Follow the naming convention standards, no cryptic variable names (click here or here for examples).
- If there is extra credit, do it. The dirty secret is that this is a trick to see if you’re going to be the person who does just the minimum, or you go the extra mile.
- Don’t get too fancy.
- Don’t show off your knowledge by manually coding a B-tree structure instead of using the “.Sort()” linq method.
- Don’t perform something that is obscure just to look clever.
- Keep your program as small as possible.
- Don’t add any “extra” features that are not called for in the specification (unless the instructions specifically tell you to be creative).
When you’re a student in college, you are required to analyze algorithms and decide which is more efficient in terms of memory use and CPU speed. In the working world, you are required to build a product that must be delivered in a timely manner. Does it matter if you use the fastest algorithm? It might not really matter. It will not make a difference if you can’t deliver a working product on time just because you spent a large amount of your development time on a section of code that is only built for the purpose of making the product a fraction faster. Many companies will need a product delivered that works. Code can be enhanced later. Keep that in mind when you’re taking your programming test. Your program should be easy to follow so another programmer can quickly enhance it or repair bugs.
For your interview, keep it simple. You should study up on general terms, in case you’re asked. Make sure you understand these terms:
- Dependency injection
- Single purpose
- Base Class
- Private/public methods/classes
- Method overloading
Here’s a great place to do your study (click here). These are very basic concepts and you should have learned them in one of your object oriented programming classes. Just make sure you haven’t forgotten about them. Make sure you understand the concepts that you learned from any projects that you checked into GitHub. If you learned some unit testing, study the terms. Don’t try to act like an expert for your first interview. Just admit the knowledge that you have. If I interview you and you have nothing more than a simple understanding of unit testing, I’m OK with that. All it means is that there is a base-line of knowledge that you can build on with my help.
Wear a suit, unless explicitly specified that you don’t need one. At a minimum, you need to dress one step better than the company dress policy. I’m one of the few who can walk into an interview with red shoes, jeans and a technology T-shirt and get a job. Even though I can get away with such a crazy stunt, I usually show up in a really nice suit. To be honest, I only show up in rags when I’m Luke-warm about a job and I expect to be wooed. If I really like the company, I look sharp. The interviewers can tell me to take off my tie if they think I’m too stuffy. If you’re interviewing for your first job, wear a business suit.
Don’t BS your way through the interview. If you don’t know something, just admit it. I ask all kinds of questions to potential new hires just to see “if” by chance they know a subject. I don’t necessarily expect the person to know the subject and it will not have a lot of bearing on the acceptance or rejection of the person interviewing. Sometimes I do it just to find out what their personality is like. If you admit that you know SQL and how to write a query, I’m going to hand you a dry-erase marker and make you write a query to join two tables together. If you pass that, I’m going to give you a hint that I want all records from the parent table to show up even if it doesn’t have child records. If you don’t know how to do a left-outer join, I’m not going to hold it against you. If you are able to write a correct or almost correct left join, I’ll be impressed. If you start performing a union query or try to fake it with a wild guess, I’ll know you don’t know. I don’t want you to get a lucky guess. I’m just trying to find out how much I’m going to have to teach you after you’re hired. Don’t assume that another candidate is going to get the job over you just because they know how to do a left outer join. That other candidate might not impress me in other ways that are more important. Just do the best you can and be honest about it.
Don’t worry about being nervous. I’m still nervous when I go in for an interview and I really have not reason to be. It’s natural. Don’t be insulted if the interviewer dismisses you because they don’t think you’ll be a fit for their company. You might be a fit and their interview process is lousy. Of course, you might not be a fit. The interviewer knows the company culture and they know the type of personality they are looking for. There are no hard-fast rules for what an interviewer is looking for. Every person who performs an interview is different. Every company is different.
What Does a Career in Software Engineering Look Like
This is where I adjust your working world expectations. This will give you a leg-up on what you should focus on as you work your first job and gain experience. Here’s the general list:
- Keep up on the technologies.
- Always strive to improve your skills.
- Don’t be afraid of a technology you’ve never encountered.
Eventually you’re going to get that first job. You’ll get comfortable with the work environment and you’ll be so good at understanding the software you’ve been working on that you won’t realize the world of computer programming has gone off on a different track. You won’t be able to keep up on everything, but you should be able to recognize a paradigm shift when it happens. Read. Read a lot. I’m talking about blogs, tech articles, whatever interests you. If your company is having issues with the design process, do some research. I learned unit testing because my company at the time had a software quality issue from the lack of regression testing. The company was small and we didn’t have QA people to perform manual regression testing, so bugs kept appearing in subsystems that were not under construction. Unit testing solved that problem. It was difficult to learn how to do unit testing correctly. It was difficult to apply unit testing after the software was already built. It was difficult to break the dependencies that were created from years of adding enhancements to the company software. Ultimately, the software was never 100% unit tested (if I remember correctly, it was around 10% when I left the company), but the unit tests that were applied had a positive effect. When unit tests are used while the software is being developed, they are very effective. Now that the IOC container is main-stream, dependencies are easy to break and unit tests are second nature. Don’t get complacent about your knowledge. I have recently interviewed individuals who have little to no unit testing experience and they have worked in the software field for years. Now they have to play catch-up, because unit testing is a requirement, not an option. Any company not unit testing their software is headed for bankruptcy.
APIs are another paradigm. This falls under system architecture paradigms like SOA and Microservices. The monolithic application is dying a long and slow death. Good riddance. Large applications are difficult to maintain. They are slow to deploy. Dependencies are usually everywhere. Breaking a system into smaller chunks (called APIs) can ease the deployment and maintenance of your software. This shift from monolithic design to APIs started to occur years ago. I’m still stunned at the number of programmers that have zero knowledge of the subject. If you’ve read my blog, you’ll know that I’m a big fan of APIs. I have a lot of experience designing, debugging and deploying APIs.
I hope I was able to help you out. I want to see more applicants that are qualified to work in the industry. There’s a shortage of software developers who can do the job and that problem is getting worse every year. The job market for seasoned developers is really good, but the working world is tough because there is a serious shortage of knowledgeable programmers. Every company I’ve worked for has a difficult time filling a software developer position and I don’t see that changing any time in the near future. That doesn’t mean that there is a shortage of Computer Science degrees graduating each year. What it means is that there are still too many people graduating with a degree that just to measure up. Don’t be that person.
Now get started on that blog!