I am a 28-year old software developer in Toronto, Canada and I was let go from my job in Jan. 2020. My superiors (direct manager and HR manager) told me it was a business decision. It was my first job after I finished my thesis-based Master's in high-performance computing and I worked there for a little over a year. I gave several interviews after losing my job and I have routinely failed in online assessments and onsite technical interviews. I am too slow in coming up with a solution and coding it or I cannot come up with a solution at all in these situations. One year has passed and I think I have only become slightly better than I was a year ago.

My bachelor's degree was in a generic engineering stream where I had no course on DS&A. This is why it took me three years to finish my thesis-based master's program which is typically 2 years long. I only started to connect the dots in my third year and began to understand how "good software" should leverage the underlying hardware. I did okay and managed to publish a conference paper. However, I still did not know enough about DS&A.

In my first job (till Jan. 2020), I did not have a specific role but I mainly worked on UI development for desktop applications (Windows Forms, WPF, VB.NET). I was mostly fixing bugs and enhancing features of the existing software products. I had no prior experience with working on desktop applications and I struggled a little with the first few assignments but I became comfortable with the tools and the code-base after that. My manager stated in my annual performance review that I am independent, can understand and work with complex code-bases but I am not efficient and fast enough and should be 2-3 times faster than I was at that time. After losing my job, I had a few interviews, failed them and studied DS&A. Since my unemployment gap was becoming bigger, after a few months I volunteered for an organization as a backend developer where I worked mostly with AWS and python. I had no prior experience with AWS but I thankfully I found it to be straight-forward and did my tasks mostly independently and comfortably.

From my first job and the AWS tasks I did, I feel I am fairly comfortable working with frameworks. I enjoy coming up with high-level solutions for problems, breaking them down into pieces and using Google to find code that matches those pieces. I can then tweak those pieces enough and fuse them back together to create the final and functional solution. I really enjoy this process but I have time and an interactive IDE to solve and debug my solutions. During interviews, I always run out of time before I can come up with an acceptable solution for a coding problem and most questions I faced and struggled with were straight-forward enough to finish within the allotted time.

As I wrote earlier, my ability to do whiteboard coding and online coding tests hasn't improved much since my job loss. I believed I was good enough to clear interviews at FAANG companies but my progress has made me skeptical. What are your suggestions for me? What shall I do so that I do not remain unemployed forever?

PS. I have not had a good work ethic since I lost my job. I was solving one or two problems a day (and sometimes none at all) throughout the year.

  • 8
    I give up, what is "DS&A"?
    – Simon B
    Jan 13 at 10:49
  • 3
    @SimonB "Data Structures and Algorithms" probably
    – JamesPD
    Jan 13 at 11:05
  • I enjoy coming up with high-level solutions for problems, breaking them down into pieces [..] - Are you sure you don't want to go into functional design instead of coding out a solution? (I do both and make a distinction between the two, and also with my employer that one is not the other). There's plenty of coders "doing the tickets" set out in functional requirements. There aren't many that think through complex scenario's, use-cases and interactions between system parts, consequences to X, Y and Z when doing A or B, etc. Might want to check out that line of work (instead) ?
    – rkeet
    Jan 13 at 13:04
  • @SimonB JamesPD is right.
    – a_sid
    Jan 13 at 17:42
  • @rkeet Are you sure you don't want to go into functional design instead of coding out a solution? If I am not mistaken, don't you need several years of experience to be eligible for such a job?
    – a_sid
    Jan 13 at 17:46

I think Snow is right about how to get your foot into the door, but I think you need to do something else to keep your job. Your previous boss said he'd expect you to double or even triple your speed. That is pretty significant. I don't think you did that yet, and I think your new boss might have the same expectations sooner or later.

I enjoy coming up with high-level solutions for problems, breaking them down into pieces and using Google to find code that matches those pieces. I can then tweak those pieces enough and fuse them back together to create the final and functional solution.

Try to do that without Google. Sure, Google is great. I would probably quit if I'd had to work without a reference manual and a Google index on it. But I come up with the solution and I use Google as a backup in case my memory fails. You description sounds like Google is a regular step in your work. If that is the case, you will face the same criticism again and again. Because by googling a solution, even when finding one, you don't learn a lot from it.

On a very abstract level, Google is the Lego kit with manual of working. Anybody can go through the step by step manual and build the kit from the correct blocks that were supplied with it. But a kid learns very little from it. Only if you drop a box of random bricks and say "let's see who can build the cooler model", will the kid think and try and learn.

I think what you should do is indeed practice, but practice to work without the help of Google. Solve your problem by trying, not by cheating and looking at the other persons test. That sounds harsh, but that is what Google is: looking at another persons work and copying it. It might be legal, it might be accepted and it might even be perfectly okay at times. We all dot it. But we do it as a last resort, not as a first strategy.

Trying on your own will make you faster, give you experience and confidence. It should also improve your interview skills, because being on your own without a tutorial is exactly what the interview is.

  • Thank you for this practical answer.
    – a_sid
    Jan 13 at 21:54
  • You description sounds like Google is a regular step in your work. In the most recent online test I did, it occurred to me arrange the given data in a 2-D array. My first instinct after this thought was to Google how to add data from a 1-D array into a 2-D array in the language of my choice (I failed this test too.). Does this example make it look that Google is a regular step in my work?
    – a_sid
    Jan 13 at 21:59
  • 1
    Yes, indeed. Transforming data this way is a regular occurrence at work and something I would expect my apprentices to do by themselves after about a year. Your education may have given you a lot of high-level knowledge, but in practice, it seems a well educated junior software engineer (apprenticeship takes 3 years here) will leave you in the dust when it comes to opening a compiler and doing it. Whether you move to a more theoretical job, or improve on your practical skill, is up to you, but that definitely seems to be the problem here.
    – nvoigt
    Jan 14 at 7:46
  • 1
    After reading your answer and those of others, I realized the most important thing I should do to secure my place in the industry is to practice solving problems and coding my solutions without an IDE's support. I'll try to more diligently solve the interview-style problems available online and see how good I can get at it by the end of this month.
    – a_sid
    Jan 14 at 10:15
  • 1
    If the interviews do not have an IDE than yes. But I would call that an artificial problem. You will have an IDE at work. The question is: does the IDE automate a task, you know how to do, so it saves you time? Or does it do tasks for you that you would not know how to do if you had no IDE? Because that would be a problem.
    – nvoigt
    Jan 14 at 10:21

The answer seems somewhat obvious, but:


You've gone through a few of these tests now and you know what kind of problems are going to be presented to you at the interviews, so you can prepare for those by practicing these exercises.

There's doubtless many resources out there to help candidates practice and prepare for technical interviews so go through those exercises - do as many as you can that align to your experiences before so that you're comfortable with them and the time needed to complete them.

To work on your work ethic, you need to timetable your day so that you have this study time blocked out and you really need to stick to it.

No one is going to hand you a job on a plate, you need to prepare for the interview and earn that position.

  • Thank you for the advice :)
    – a_sid
    Jan 15 at 2:02

One of the most important statements I picked from your question is:

During interviews, I always run out of time before I can come up with an acceptable solution for a coding problem and most questions I faced and struggled with were straight-forward enough to finish within the allotted time.

This raises a number of questions for me and I feel you should do an honest evaluation of your coding to see where the time goes. A number of things come to mind, but the top two are:

  • Simply interview anxiety. When in a fearful state, we are not as logical as we normally are. Practice interview quizzes - with time, build confidence in your ability. If you are sure you can, you will be in a lesser fear state and think better.
  • Suffer from code perfection. It is very easy to over-work code to try and make it "perfect". See if you do this, and if so practice to stop doing it. Avoid worst practices obviously, but realize you do not have to hit every best practice. An "acceptable" solution for the interviewer is likely a working solution to the problem, in reasonable time, without obviously flaws.
  • Thank you for the answer. It is definitely interview anxiety :).
    – a_sid
    Jan 14 at 19:03
  • Not being properly prepared to tackle this type of questions has been a bigger hindrance I think than interview anxiety. Before an interview, I try to cover as much ground as possible because in majority of the cases, I do not know what the interviewer will focus on. This causes muddled thinking and adds to my anxiety. Moreover, I wrote near the end of my question that my work ethic throughout the year of 2020 was not very good. Perhaps if I manage my time better as Snow suggested I'll be more confident and less anxious.
    – a_sid
    Jan 15 at 2:02
  • 2
    Let's face it, 2020 has not been normal, so don't beat your self up (too much). Time management is a good thing to work on in 2021, if you recognize a deficiency
    – Chris
    Jan 15 at 4:25
  • True. I just hope that I don't take too long now to develop good work habits and get a job I like.
    – a_sid
    Jan 15 at 19:29
  • Not to be harsh, but I'd focus on "getting a job I don't hate" and taking a year or two, then a "job I like" ;)
    – bytepusher
    Aug 28 at 17:54

It's possible your problem is that you don't know how to solve an interview question. There are a million videos on this from interviewers at every FAANG company, but to give you the TL;DR this is what you need to do:

Step 1: Understand the problem. The interviewers often leave a lot of ambiguity in the question they ask, and that's important. They are testing you to see if you can recognize ambiguity and ask appropriate questions to resolve the ambiguity. This is part of the interview, they are actively trying to trick you and see what happens what you do. And if you think this is mean-spirited, it happens literally all the time at work, where you're given some requirements by some business person who doesn't know an if statement from a for loop, and you have to ask many questions. They want to test that you are able to know when/how/what to ask in those situations.

The best way to pass this part is to ELI5 the question back to the interviewer. They'll say "You need to print every number, except instead of multiples of 3 you print Fizz and instead of multiples of 5 you print Buzz". They've intentionally not told you what if a number is a multiple of both 3 and 5. You need to ask: "what happens if a number is a multiple of both 3 and 5?", and if you don't, you fail immediately. Then, they'll say: "on multiples of both 3 and 5 you print FizzBuzz". So you repeat: "So I print, 1, 2, Fizz, 4, Buzz, Fizz, and so on, until 14, then FizzBuzz, then 16, 17, Fizz, and so forth, do I have the right idea?", and they'll say "yeah, you have it right". Then you can move on to step 2.

Step 2: Pseudocode your answer. So now you understand the problem. It doesn't matter if you give the best answer; it's better to give a sloppy first answer and refine it later than to waste time trying to impress the interviewer with how smart you are. The test is "can you find a solution?", and that's it. They want to test your problem solving and critical thinking skills, so just show them you're smart enough to come up with something that works.

So you say: "OK, so first I'll write a loop that counts from 1 to n. Each iteration of the loop, I'll check if it's a multiple of 3 and set a flag, and I'll check if it's a multiple of 5 and set a flag. If the 3 flag is set, I'll print Fizz, if the 5 flag is set I'll print Buzz, and if both flags are set then I'll print FizzBuzz". Don't worry about putting this in code, just say it exactly like that, and you may want to put that on the whiteboard provided in point form.

The interviewer may give you feedback at this point, or they may not. If the problem is difficult, you may run into bugs at this point. Don't be afraid to look stupid; it's better to find a bug here than it is to find a bug later, and it's fine to find a bug in your algorithm so long as you're able to figure out how to fix it.

Step 3: Write code. This is where you actually write the code. Translate what you prepared in step 2 into code in your language of choice. Don't get fancy though and try to do optimizations at this stage. You thought out your solution in step 2, that's where all the thinking is. This step is just rote translation. The test here is "can you implement an algorithm that's given to you?". You wrote the algorithm in step 2, now you just have to translate exactly what you wrote into code.

Make sure you are writing your code in such a way as the interviewer can understand what's what, and how your solution is the same as what you wrote in step 2. Don't throw the interviewer any curveballs, don't try to be fancy, don't try to "optimize". I can't emphasize this enough. Just translate, beat for beat, point for point.

Now you have a solution that works and the interviewer knows you can code. Then they might get into optimizations, or curveballs, or "what if"s, and you have to deal with those. Just repeat the above 3 steps to handle them.

For example, the interviewer might say "What if I told you you're not allowed to use a for loop for your FizzBuzz program?". So you say "OK, I can't use a for loop, but I can use a while loop, right?", so then he'll say "yeah sure". So you rewrite your code, using a while loop instead of a for loop, or whatever. Maybe he says "no loops" so you have to do recursion. Or maybe he says you need to respect a start index as well as an end index. Or maybe he adds a new word instead of just "Fizz" and "Buzz". But whatever he says, you just follow the same pattern to answer: Understand, solve (pseudocode), real code.

Try that, it should help.

  • Thank you for the comprehensive anwer :)
    – a_sid
    Jan 15 at 2:03

I think the most important thing to keep in mind is that this is a numbers game. I have applied for literally hundreds of jobs, and had over 50 interviews during my career. That puts my success rate from application to offer at less than 2%. However, I have always been able to get another job eventually. So you really need to maximise the number of jobs you apply for - just apply for anything vaguely suitable which meets your salary requirements, regardless of what it is. At the very least you will get more interview practice even if you don't really want the work.

From my experience, coding tests, especially timed tests, are a very crude measure of a developer's productivity and value. I have been in software development for more than 20 years, and have had to do countless coding tests and coding in interviews, and find that the tasks are usually difficult and obscure.

However, the main thing to keep in mind is that much of the time the expectation is that you will not complete the task. The outcome of most interest to interviewers is the code you write, not whether or not you complete the task. They want to see well structured, well composed, testable code.

This type of code is only possible to write when you have planned high level, broken the task down, and have access to reference materials; in short, what you already do.

Something which really helped me in coding tests is adopting TDD. If you do TDD you automatically write testable code, plus you focus the mind on the actual outcomes you want from the code. Additionally, doing TDD in an interview demonstrates an important skill to the interviewers.

  • They want to see well structured, well composed, testable code. I am aware of this but the fact of the matter is I have been failing to do this even for straight-forward questions. Lack of preparation, fear of the unexpected, etc. have all led to the rut I am in. I hope I can get my affairs in order soon.
    – a_sid
    Jan 15 at 19:38
  • Thank you for the answer and writing code with the TDD approach in interviews is a helpful idea.
    – a_sid
    Jan 15 at 19:43

You must log in to answer this question.

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