34

I just got fired from my job. It was my first software engineering job out of college, and I was there for just over a year. The reason was that they do not think they can train me to have the skills they need within a time frame that would work for the company. I thought that I was good enough and rapidly improving, and I even received 2 positive performance reviews last year.

I had a hard time getting that job. I'm not good at coding tests. I've had them from 9 different companies and passed 3 of them. I prepare for them regularly using materials.

Additionally, I had a summer internship in 2016 that I tried to convert to a full time job, but they basically said they would keep me as an intern but were not willing to employ me full time.

Academically, I was great. I finished my Master's of Computer Science with a 4.0 GPA from a top 10 comp sci program, and I finished undergrad with a computer science minor with a 3.70 GPA.

I like being a software engineer, but I feel like there's no good way to evaluate skill. How can I figure out if I'm actually bad, or if I just need to keep practicing more?

Two and a half year Update: I found a good job as a software engineer and excelled at it. After 2 years, I left for a better software engineering job. I'm now good at coding tests, but I know that in general it doesn't mean that you are a good software engineer or not. Neither does getting fired one time. I am now pretty confident I got fired because they found out I was on the job market and they thought it would hurt their reputation if I quit (they had some high profile people quit in the months/years before I quit).

26
  • 18
    There are a lot of different kinds of software engineer. Some build websites, others work on embedded systems. You might work directly on a product that is sold, or manage backend systems that support the rest of the business. All require their own unique skills and being good at one type of work doesn't necessarily mean you will excel at others. Were your skills and talents aligned with the type of work you were trying to do?
    – Seth R
    May 23 '18 at 2:18
  • 7
    How large was the organisation? Startups and smaller companies tend to demand a faster learning curve out of their staff.
    – Jane S
    May 23 '18 at 2:36
  • 4
    Were you working with other programmers? At what level etc. If you were found wanting by a team who know what they were doing and have experience onboarding juniors, that's different from being fired as only developer at a start-up with entirely unrealistic expectations. May 23 '18 at 2:50
  • 3
    @TheComeBackKid you're going to do just fine! Stop being so hard on yourself. I'm happy for you. Now you can finally go get a real job and be appreciated. Screw those idiots for firing you. They don't know what they lost.
    – user7360
    May 23 '18 at 14:24
  • 4
    Thanks for the update! This is a great example of why you should never take other peoples' opinions about what you can and can't do too seriously. Really glad to hear things worked out for you. Sep 23 '20 at 23:20

10 Answers 10

37

How can I figure out if I'm actually bad, or if I just need to keep practicing more?

Given your positive performances throughout your former job and your excellent scores obtained during your whole academic career I'd risk saying that you are actually a good engineer.

So first thing I suggest is to take it easy on yourself. I know you may feel like this now, as this happens when one loses a job which you poured your energy and dedication to. But honestly, there is nothing positive for you on keeping feeling this way after such negative experience, as it will not help you move on.

That being said, some piece of advice I can give you is:

  • Don't be let down by one company laying you off after one year (which is decent time) because "they can't train you to have the skills they need within a time frame". Many companies have really unrealistic high expectations/timeframes from their developers, and sadly many of them see us as expendable code monkeys that they can just squeeze until depleted (sometimes they don't do it because they are "evil", just the way their industry and market works).

    However, many other companies are not like that, so it's nor fair for you to cast away your hopes because of this incident.

  • Nevertheless, a professional should never stop practicing, even though they were the best out there. Most successful professionals and engineers never stop learning. In Michelangelo's words: Ancora imparo. That is why I suggest that you view all this as yet another opportunity you had to learn and grow; keep the good things, remember the bad things (which happen to be the ones that teach us), and move on. Many other interesting jobs and things await you out there if you give them the chance to come.

Having said all this, I think that what's left to say is good luck, update your resume, start job-hunting, and be confident in your skills. Your "comeback"... ;) ...awaits you.

5
  • 3
    Thank you. It definitely could be the case that their expectations were not attainable. I am definitely trying to get another programming job. Maybe if the next one ends similarly, I will reevaluate. May 23 '18 at 3:27
  • Yup, take it easy and don't be let down by one company.
    – Sandra K
    May 23 '18 at 3:28
  • 2
    @TheComeBackKid also, don't just take any job. Carefully chose them so you don't end up with a sweet and sour experience like this again. I know job-hunting is hard, but perseverance is key here. Glad I could help.
    – DarkCygnus
    May 23 '18 at 3:42
  • That's good advice. How do I know what kind of job to take? Are there some qualities in particular you think I should look for? May 23 '18 at 12:20
  • @TheComeBackKid That I fear is the part you have to decide for yourself. I can't tell you what job to chose or what qualities your should look for, but if you trust your gut and your Principles you will know.
    – DarkCygnus
    May 24 '18 at 17:17
8

I just got fired from my job. It was my first software engineering job out of college, and I was there for just over a year. The reason was that they do not think they can train me to have the skills they need within a time frame that would work for the company. I thought that I was good enough and rapidly improving, and I even received 2 positive performance reviews last year.

Don't take it personally. What they did was a business decision, the anticipated ROI investing time, money, and developer attention was < what you could bring back. If you fixate on the fact that you were terminated, it will eat you for months to come. The best thing you can do here is to take some time to decompress and reevaluate your current skillset, decide on a career destination, and set sail. Don't linger in port sulking.

I had a hard time getting that job. I'm not good at coding tests. I've had them from 9 different companies and passed 3 of them. I prepare for them regularly using materials.

After graduation, I applied to 600+ positions, had only about a dozen interviews, and only 1 offer - which was terminated this past January. The only option that leads to your next job is to get back on the horse again.

Additionally, I had a summer internship in 2016 that I tried to convert to a full time job, but they basically said they would keep me as an intern but were not willing to employ me full time.

Perhaps this is an opportunity to ask if they are hiring. You now have a year's worth of exp under your belt and has a better skillset than you were from college. Maybe this would be a good option to ask since they knew you from before.

Academically, I was great. I finished my Master's of Computer Science with a 4.0 GPA from a top 10 comp sci program, and I finished undergrad with a computer science minor with a 3.70 GPA.

I can recall that after your first job, GPA isn't as a big of a deal. But I could be wrong; don't forget to include this info on your resume and talk about it during the interview.

I like being a software engineer, but I feel like there's no good way to evaluate skill. How can I figure out if I'm actually bad, or if I just need to keep practicing more?

I'd agree, there is no reliable way to measure skill, given that the problems that you face are never one and the same, determining whether or not you are 'better' or 'worse' will lead down a rabbit hole of self-doubt and paralysis. Until your next full time position, perhaps look into contract roles? This way, you can practice and get paid on smaller projects.

3
  • Thank you for the details. I'm glad there's evidence that I'm not the only one applying to hundreds of positions without much luck. I will check out the freelance stuff. May 23 '18 at 16:23
  • There are some pretty reliable ways to measure skill. For example, one can compare the time it takes developers to solve a problem on (projecteuler.net) or (leetcode.com), or their ability to solve the problem at all. May 25 '18 at 1:09
  • 1
    Solving a predetermined puzzle or problem is one measurement, but it does not encompass everything that is part of the day-to-day tools of a developer. In other words, there is more to the job than programming skill, interpersonal skills are a must as well. No one codes alone in the modern era, as evident by stackoverflow and github.
    – Bluebird
    May 25 '18 at 17:20
7

A high GPA is nice, but software development is a performance profession. You have to be able to produce working code at a reasonable rate.

When you say "I'm not good at coding tests" do you mean that you struggle to produce working code during an interview? If that's the case then you will have to practice to be competitive on the job market. I interview candidates all the time and no one gets hired if they can't demonstrate an ability to code during the interview. So either start a personal programming project in some area that interests you, or maybe pick a new language and work through problems like those at Project Euler.

2
  • Most of the coding tests I passed (2 of the 3) were during an interview. It's the ones that are on hackerrank that I tend to fail. For example, one I struggled with recently was called "Friend Circle" (leetcode.com/problems/friend-circles/description). I had about 2 hours to complete it on my laptop. May 23 '18 at 12:09
  • 2
    @TheComeBackKid Now you know what to work on: other problems from that same website. Maybe get a copy of "Introduction to Algorithms" by Cormen and work through that. May 25 '18 at 1:01
5

The fact that you were fired doesn't mean you're a bad engineer. It means you were not a good fit for the role you were in.

If you feel you can improve, you should improve. If you feel you are a good engineer, you should start checking for additional options. Luckily enough you are in a position to find a job since engineer jobs are in high demand, you just need to define what you are after, learn your options, make sure the job matches your skills (not just the technical) and keep improving.

Best of luck.

1
  • 1
    It doesn't even mean unequivocally, that he wasn't a good fit. Most companies I have ever seen have spurious and random HR stuff in the books, somewhere. Some companies and bosses - are more capricious than others. They appear somewhat randomly distributed, but there is a correlation between the two. Jun 24 '20 at 10:00
3

It was my first software engineering job out of college, and I was there for just over a year. The reason was that they do not think they can train me to have the skills they need within a time frame that would work for the company.

Many companies (usually middle to smaller ones) do not hire new grads just because they can't provide the right environment/right tasks. Generally speaking, the company needs to be above a certain size and have a certain level of maturity in order to have new grads. So, especially if the company was on a smaller end and/or they didn't have many more new grads, the problem could have been on the company's side rather than on your side.

Of course I don't know if that's the case, but you shouldn't doubt your ability based on one example. I have seen MANY excellent people being laid off for one reason or another. Many layoffs aren't due to aptitude problems.

3

You're asking the wrong question. What do you want to be?

Having been in a somewhat similar situation, what I came back to is this: programming is what I've done for fun for the last 27 years. I like it and it comes naturally to me (with practice of course!). I am a programmer. Does that apply to you, or do you find you have to force yourself to like programming and to do it regularly? By contrast, I have to force myself to do creative writing. When I do it, I enjoy it and I think I have a knack for it, but I would never just do creative writing as a hobby. I'm just not a writer. So I think this is question number one, and you'll need to look at your personal history, not your emotions to answer this one. What you do demonstrates what you love far better than what you feel ever could.

You'll work harder at what you want and gravitate toward your skills

Most people don't work as hard at things they don't want deep down. They don't learn as fast and they don't grow as fast. And if something comes especially hard for them, they often don't work as hard at it either (with exceptions of course!). Conversely if you truly love programming (again based on your history not your emotions right now, which are understandably going to be a bit of a mess), you're going to naturally work hard at it and grow, and all the more if you have natural talent as a developer. So if you've been programming for fun for years and haven't given it up, I'd say you have 100% of the foundation you need to be a good programmer. After that it just takes practice and learning how to fit into the corporate machine, which is an entirely different set of skills.

Where to go from here

Ditto about not taking it too hard. Make sure you don't beat yourself up over this. It happens to many of us at some point in our career, and it's not the end of the world. There's a next job after the previous one. Having said that, each bad experience in life is an opportunity that we can learn from. So it's worth looking back at what happened and asking what you can learn from it. Ask yourself if there were any subtle cues you might have missed that they were unhappy with your performance. Sometimes managers aren't great at communicating, or communicate displeasure passive-aggressively in ways that are really easy to miss. Did your manager or team lead repeatedly ask if you were enjoying the work? Did you repeatedly have no new progress to report at status meetings? Did they ask for the same corrections/changes several times? I'm not assuming any of these things did happen, but it's worth reflecting on whether there could have been any cues you missed. Because those would be opportunities to learn for next time. Conversely, did you miss any red flags that this is a toxic environment or that you had a bad manager? Did you miss any red flags that the company was in financial trouble or that layoffs were coming? Developing an increased self-awareness and awareness of your corporate surroundings is a very valuable takeaway from a painful experience like this. But at the end of the day, 1) figure out what you want to be (from your personal history), 2) dust yourself off and get back up on the horse or move on if programming isn't for you, and 3) reflect and learn whatever there is to learn from this experience.

2

Ok, you were fired for performance reasons. If you are in the US, have you applied for unemployment? Keep in mind, that unless you were fired for cause ( ie, a physical altercation, sexual harassment, ... ) you can still collect unemployment. Most companies I’ve worked for laid me off for performance reasons, that is after a couple of years of good performance reviews. Even if the letter they gave you says fired, if you collect unemployment, it was a lay off.

The first time was a surprise for me, and I too took it hard, The next times, not a surprise. Often it has been a new manager who is cleaning house to install their favorites. My point is to get over being laid off.

You’re response is very typical of people who are very competent, that is impostor syndrome.

Now start looking for a new job. Expect it will take you a about 4 months. Spend 5 hours per day doing job hunting tasks. Generally I try to find 10 reasonable jobs to apply for and 5 that stretch me per day. Remember, they ask for God, but will accept Christ.

Find an open source project to join and work on. Work on it this for 2 to 4 hours per day. Bonus points if the project you are working on is being sponsored by a company you want to work for.

Great, you have a top 10 degree, but keep learning and practice more. This might be focused on the open source project, or a topic you just want to learn. It may help you figure out if you want to do this for the long haul.

Seriously, don’t pay too much attention to metrics, Norris numbers, lines of code ... . Work on being a team player and motivating yourself to learn what you need to learn to do.

Finally, Find a hobby to recharge your battery as so to speak. Anything you have fun doing.

Best of luck.

0

1) How to know if you're a good engineer? Well, that part is fairly easy. There's really no such thing as a "bad engineer"; you're either an engineer or you're not. Once you have determined that you are an engineer, the difference between "good" and "bad" is skill development, and that's a learned skill (meaning if you're a "bad" engineer now, you can learn to be a "good" engineer with experience). Given the context of this question, I presume you are an engineer, so the rest is just practice and learning.

2) School doesn't really prove anything. I personally have both a Bachelor's and a Master's degree in Computer Science from one of the top schools in my country. I have a job as a software engineer. Do you know how much of the stuff I learned in school that I use on a regular basis? Almost zero. So to be honest, your schooling and your GPA is probably more useful as an abstract measure of your learning potential than it is a measure of your concrete skills. So while I wouldn't say that having a high GPA correlates with being a "good" engineer, it also doesn't correlate with being a "bad" engineer. What it does correlate with is your ability to change from being a "bad" engineer to a "good" engineer. As a result, I wouldn't take GPA into account for basically anything related to this question, I think it's a red herring.

3) As for your interview skills, most of that comes with practice. Presumably you took an Algorithms & Data Structures course in school, and since you have a high GPA I presume you did very well in that. To become "good at" answering interview problems, you should recall (or re-study) the material from that class in particular, because most of the questions you will be asked will be answerable from that material. After that, it's just practice. You'll fail the first few times, but then you'll get used to seeing what they want, and you'll begin to see the same types of problems over and over and you'll get better at answering them. It's just practice. That said, the practice is answering questions in an interview-type environment; going over questions on something like HackerRank or whatever has limited value; you'll practice certain skills/algorithms, but if they're not the ones the interviewer asks, then it doesn't matter. What is better is learning to come up with good answers on the fly; no interviewer wants to ask a question that you already know the answer to, what they want is to see how you come up with answers on the fly to questions you didn't know ahead of time.

3
  • @JoeStrazzere I mean that a "bad engineer" is just a good engineer who doesn't know how to do things properly. Nobody is inherently a "bad engineer" in an abstract sense; someone who could be considered a "bad engineer" can be taught to be a "good engineer" by learning good engineering practices/principles.
    – Ertai87
    Oct 24 '18 at 18:05
  • @JoeStrazzere As I said in my answer: I think (my opinion) that the OP's GPA is a good indicator of the fact that the OP is willing and able to learn to be a good engineer.
    – Ertai87
    Oct 24 '18 at 18:31
  • @JoeStrazzere Would you like to suggest an edit? ;)
    – Ertai87
    Oct 24 '18 at 19:03
-2

Software isn't something you practice, like rehearing for a music recital. It's something you just get on and do. You have a bit of code that needs to be written to meet a particular need. You keep plugging away at it until it works. At the end, you have probably learned something. Then you move on to the next job on the list.

As time goes on, you get better at it. Until the system you're used to working on is obsolete, and you are on to something new. Then it's back to plugging away at it until you manage to get it to work again.

There are lots of jobs in the software in addition to being a code monkey. There's the graphical design of user interfaces, there's requirements analysis, there's systems engineering, there's testing. There are probably other things I've forgotten.

If you think you might do better at any of those, look around at who's recruiting and try something different.

4
  • 3
    I'm not sure why you think programming isn't something to be practiced. That's what "getting out and doing" is, and in terms of time required, it's much like musical practice, but for a different activity. The CS graduate who never did any extracurricular programming is generally much less adept than the graduates who spent their free time working on personal software projects. May 25 '18 at 1:05
  • See norvig.com/21-days.html for counter-arguments to the claim "software isn't something you practice" May 25 '18 at 5:23
  • @BasileStarynkevitch Thanks for sharing this. Very informative. I especially liked this quote: "the maximal level of performance for individuals in a given domain is not attained automatically as a function of extended experience, but the level of performance can be increased even by highly experienced individuals as a result of deliberate efforts to improve."
    – Lumberjack
    May 29 '18 at 14:18
  • 1
    Developing something, running into obstacles and overcoming them, thinking problems and finding different approaching how to solve them, discussing and sharing ideas with others, etc. These all are practice. Being developer is literally just practicing constantly.
    – Sopuli
    Oct 23 '18 at 17:14
-2

I'm going to focus my answer on the last part here as it relates to something I've been thinking about for a few years now:

I like being a software engineer, but I feel like there's no good way to evaluate skill. How can I figure out if I'm actually bad, or if I just need to keep practicing more?

The Norris Number scale is a metric by which individuals and organizations can measure themselves.

Norris Numbers start at 20 and increase by multiples of 10. They correlate to an increased understanding of the fundamental design and structure of any given software application.

For the purposes of this answer, the Norris Number is a measurement of the lines of application code, minus libraries, that an individual can write and maintain by themselves.

Everyone starts out at 20 Norris. Most formal programmers move up to 200 Norris pretty quickly. 200 Norris programs are usually quick-n-dirty scripts that do something important but just do that one thing. Such programs are "thrown together" which means they tend to lack proper code formatting and error checking - especially from newer programmers. Many programmers move onto 2,000 Norris as they start building larger programs/scripts.

Going from 2,000 to 20,000 Norris outside of a team environment is a lot harder. You have to be building a serious application at that point. A lot of doors open up at 20,000 Norris (e.g. large open source projects). Getting past 20,000 to 200,000 Norris on an individual level is quite difficult since there aren't that many software applications out there built by one person with 200,000+ lines of application code. That's generally too much for one person to sanely and actively maintain.

Norris also indicates comfort level. At what point can you write an application "in your sleep"? That is, the amount of mental effort required to go from idea to deployment. Those graduating with a CS degree tend to be 200 and less commonly 2,000 Norris. It's very rare to find a 20,000 Norris developer right out of college. Such developers usually start writing software long before college and they view the diploma as a very expensive piece of paper.

An organizational Norris Number is similar but is the average number of lines of application code per application spanned across the entire organization. Most organizations are 2,000 or 20,000 Norris. Small businesses with an IT department that develops tiny scripts for the organization are usually not more than 200 Norris. An organization can also have a 2,000 Norris average but might have one or two 20,000 Norris applications lurking inside that bump up the average slightly but not enough to get it to 20,000 Norris.

If an organization is 2,000 Norris and the individual is barely 200 Norris, the individual will have a difficult time keeping up (i.e. it will be a challenge to stay afloat). If an organization is 20,000 Norris or is hiring for a 20,000 Norris application and an individual is 200 Norris, the individual probably won't get hired without lying their way into the job but the individual won't survive more than a few weeks anyway. If an organization is 200 Norris and the individual is 2,000 Norris, the individual will likely be bored and find it difficult to stay interested in the projects that come along (i.e. a lack of challenge). Also, someone at 20,000 Norris will regularly discover that communicating with someone at 20, 200, and even 2,000 Norris is awkward or difficult. The person at the lower Norris Number level simply won't understand the purpose of certain decisions and may try to "refactor the code" or call the person at 20,000 Norris a "bad software developer". In my experience, the only "bad" software developer is the person who (unintentionally) writes code with security vulnerabilities in it and then participates in active denial when the vulnerabilities are pointed out by peers.

Norris Number alone can, as long as all parties are truthful about it, determine whether or not to hire (or even fire) an individual. It's also possible for an individual developer to outgrow an organization or vice versa. When relying on an honest Norris metric, the in-interview coding test could be skipped, which can really only measure up to 200 Norris in the time allotted for the average interview. Norris Number could be a really good filter for a job search engine for software developers and I strongly suspect other industries have similar metrics that they could similarly leverage.

Instead of practicing problems, which tend to focus on algorithmic design, focus instead on projects. What projects are of interest to you? Create a list and start building THOSE projects in your spare time. The whole point of software development is to build what is interesting to YOU. Software is an art form filled with elegance and beauty. Yeah, you can get paid for it too but if you aren't already doing what you love outside of a formal job, then you should start doing that. Otherwise you'll work a job for 40-ish years and yet your life will be empty and devoid of any personal achievements.

4
  • You seem awfully enamored with the Norris Number - something that in the words of John Cook (who blogged about it) is described as "This is meant to be humorous, not scientific." SLOC has a significant number of drawbacks that make it a poor metric for sole evaluation of a developer's skill. Any hiring (or firing) process that used that "alone" would be disastrous in my opinion.
    – motosubatsu
    Oct 23 '18 at 16:27
  • I disagree. Unlike a strict SLOC measurement, Norris is a scalable metric. And in my experience, it has held true unlike SLOC. As a developer hits each Norris wall, they have to rethink their strategy to software development if they want to keep going. There is no direct correlation between SLOC measurement and Norris. I also very clearly state that application code is the only part of Norris. Libraries are excluded. When someone writes a 500 line app that leverages millions of lines of library code (even if they wrote the libraries) - it's still a 200 Norris application. Oct 24 '18 at 2:05
  • I also said that "if all parties are truthful about it" Norris could be used exclusively. Everyone always presents their best side in an interview (both the interviewer and the interviewee). So reality is obviously going to look different. The OP wanted to know if they were a good or bad developer. I provided an answer that gives them a calculation tool they can use for themselves to evaluate themselves (and any organization they might want to work for). None of the other answers here have even attempted to do that. Yeah, I'm a bit enamored but it didn't really deserve a downvote. Oct 24 '18 at 2:17
  • I never said anything about the truthfulness or not - if anything I evaluated that on it being the case. I also never said anything about libraries or not - they wouldn't be counted under a SLOC KPI either. And the content of other answers is irrelevant to my evaluation of yours - I downvoted because it's a crap metric (and doubly so if used in isolation), all the disadvantages of SLOC apply to Norris as well.
    – motosubatsu
    Oct 24 '18 at 8:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .