13

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?

  • 10
    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
  • 2
    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. – Nathan Cooper 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
  • 2
    I love that you signed up with the name @TheComeBackKid to ask this question. – user86764 May 23 '18 at 23:43
29

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.

  • 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. – TheComeBackKid 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
  • 1
    @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? – TheComeBackKid 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
6

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.

  • 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. – TheComeBackKid May 23 '18 at 12:09
  • 1
    @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. – kevin cline May 25 '18 at 1:01
5

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.

  • 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. – TheComeBackKid 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. – kevin cline May 25 '18 at 1:09
  • 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. – Frank FYC May 25 '18 at 17:20
3

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.

0

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.

-1

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.

  • 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. – CubicleSoft 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. – CubicleSoft 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
-1

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.

  • @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.

  • 2
    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. – kevin cline May 25 '18 at 1:05
  • See norvig.com/21-days.html for counter-arguments to the claim "software isn't something you practice" – Basile Starynkevitch 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.