Unemployed for a year and struggling to clear technical interviews

Question

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 Data Structures and Algorithms (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.

Answer 1

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.

Answer 2

The answer seems somewhat obvious, but:

Practice.

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

My bachelor's degree was in a generic engineering stream where I had no course on Data Structures and Algorithms (DS&A). This is why it took me three years to finish my thesis-based master's program which is typically 2 years long.

These two sentences are telling a lot (even if just the most direct example in your question). You connect a complex issue to a simple fact. For me that would be a red sign, for two reasons:

• DS&A are so intrinsic to coding that i would expect a candidate to show interest on their own if they are good coders.
• Unlikely that was the sole reason that you took three years - please interpret this with more distance
• Maybe taking three year is not an issue at all if you don't make one out of it

So kill this perceived problem from you mindset, even if it bothered you during the studies.

In my experience, the only thing which makes you better at coding is working on (little or big) projects and reading a lot of other peoples real life code.

Answer 7

In the current world wide shortage of software developers, it is quite an achievement to be actively looking for work as a developer, and to not find it. Whilst that can happen to anyone for a couple of months, as its been over 6 months, that suggests that just carrying on and hoping, is not likely to be a successful strategy.

if I was recruiting and saw your CV, there are 2 issues that I would pick up on.

1. Your degree. The way that you have described it, suggests that it was a computer science degree, rather than a software engineering degree. That is a yellow flag for me. I would be looking for further evidence of programming, as a hobby, or in your final year project. Without that, it is unlikely that you would already be skilled enough for taking on project work under supervision, and would need substantial on the job training.

2. Desktop Application development. There are some companies that still write desktop applications, but not many. Most people are writing mobile apps and web sites, and they are mainly doing it in C# not Visual Basic. Again, of the coding you have done, how much of it is directly transferable into your next work environment?

These two issues combined would go a long way to explaining your difficulties in finding software development work

---

However, it is not all bad news.

Having direct AWS experience is highly desirable. Having python experience in AWS writing lambdas is a good skill to be able to demonstrate, and you seem to have found a top down way of thinking about software programs.

The challenge with a good quality technical interview is that it allows the interviewer to understand how you work through a problem. They are not looking for perfection, but they are looking for a good practical approach. May I suggest that you practice on a few internet examples of programming interview challenges with a friend, taking them through the following phases:

1. Understanding - Making sure that you understand the problem.
2. Analysis - What is the input data? what is the expected output data? what are the processes that need to occur? Is this a write a function task? or create a few classes that work together?
3. Design - Pick on the principle process and work out the ordered list of the actions and decisions that this process needs to perform to produce the output.
4. Implement - Write code that implements the process that you defined.

With this structured approach, there are 3 key parts that you need to do well.

• Communication with the interviewer.
• Select an appropriate code structure for the task.
• Implement your design (not diverging from it).

If you do these 3 things well, you will start getting 2nd interviews and job offers will become more likely.

From an interviewers perspective, I'm wanting to see that you can have a technical conversation with me, that you are thinking about what you are doing, and that you can translate a design into code reliably.

---

The final part, is what kind of jobs should you apply for?

Simply, you want to be competing against graduates. Go for entry level jobs, and use your bits of experience to give you a bit of an advantage. Go for teams that are working on a Web stack technology, with AWS, and stick to C# jobs for now. This will give you work experience with very transferable skills for your next job...