It has been a while, a lot longer than expected since my last post. I have been very busy the last few months doing a lot of coding challenges as I have been interviewing at various companies. I have to say it has been an interesting journey especially being someone who interviews engineers as well.

Being from New Zealand the job market is a lot smaller and has interesting dynamics. I did apply for jobs abroad but none of them were in the USA. Also some of the companies were large but they were not at the scale of Google or Amazon.

Your CV matters

I initially just tried the shotgun approach which meant my CV went to a lot of recruiters and some businesses directly. The response rate was very low, it had been a long time since I had looked at the structure of my CV.

I had a friend of mine look over my CV and he gave a lot of feedback, and I ended up changing my CV significantly based on the feedback. Updating my CV and combining it with only applying directly to companies I was interested in and matched my skill set meant I had a significant improvement in response rate for either a phone screen or coding challenge or in some cases straight to a on site.

The Lazy Companies

I was surprised at this actually and I guess it was to be expected from my shotgun approach earlier. There were a number of lazy companies or recruiters who essentially didn’t look at my achievements on my CV, instead probably just picked out the fact I had Java as a skill. Then proceeded to ask me questions which are on the first link from Google when you search “common interview questions", such as:

  • What does transient keyword mean in Java
  • Where can the final keyword be used in Java

I don’t have a problem with these questions in general but they should definitely be tailored to the experience the candidate has. If the next step is a coding challenge then, I’m not sure what companies gain from this. Being a senior software engineer, I expect to be challenged on complex problems and/or problem solving skills.

A first interview should probe the candidate about their previous role. Does it match with what is on their CV? Can they actually give specifics on their deliverables? It is also a good chance to test the candidate on some technical skills. I would pick a problem where the first solution is usually going to be suboptimal and then optimised further in various ways.

Coding Challenges

As a engineer this I find this the interesting part as it is the part which gives you insight into how technology operates at the company. I was glad to see many of the companies which gave a coding challenge ensured they tested aspects which were relevant to their business. Though one coding challenge was not relevant to my skill set, so I emailed back saying I cannot proceed as the technology stack is outside my skill set.

There are some downsides to coding challenges and I’m going to list them out.

  • Companies which say ‘take your time’ but actually want the solution in a week.
  • Companies which give you 90 minutes to solve a problem which is geared to their business. These businesses generally don’t seem to change the problem given out for years.
  • Tests which require 20-30+ hours to finish. This is just excessive in my opinion.
  • Companies who care only about correctness of the solution.

The last point is only possible if the company gives feedback, which I like because it helps you learn from your mistakes. I received feedback from one company which was the code was clean and also showed some concurrency unit tests which apparently no other potential candidate had shown before in tests, but was still rejected because of a missing feature (see paragraph below) and a scenario I thought about but thought it wasn’t important to implement, well they specifically called it out in the feedback. In this situation I think the rejection was fair since I did actually miss a written requirement.

One of the pitfalls I fell into was getting super excited when a company I really wanted to work for sent a coding challenge after the phone screen. Looking at the problem and implementing it and sending it off after completing it in two days (I don’t have children so I have lots of spare time), then they came back with sorry, it wasn’t good enough. What?! It did what it was meant too and coding style was great. I took this as a learning opportunity and I went back and looked at the original email they had sent me and it made me sad. I should have calmed down and taken the approach I do in my day job, which is to look at the requirements and list out each requirement, then write a small blurb about how to meet the requirement. It would have meant I didn’t miss one and probably progressed to the next round.

Conclusion

Overall, my experience was good and I actually learnt a lot on this journey, some new coding tricks and questions. I learnt a lot before applying to certain companies as a lot of them have engineer blogs and share their knowledge. The thing which really grinds my gears is the companies which do not get back to you with a rejection, those are the companies I won’t be applying at again.

The stats after I got my CV in order

  • Applied at 10 companies
  • 2 companies rejected my applications (1 gave no response)

The technical interview/coding challenges for 8 remaining companies

  • 1 company was rejected by me (skills mismatch)
  • 3 companies rejected me at this stage (2 gave no response)
  • 4 proceeded to further conversations

Further Interviews:

  • 1 company was mutual agreement not to proceed further as I couldn’t meet their commitments for the next stage.
  • 1 company rejected me, with positive feedback. They were looking for a full stack engineer, but my skill set would be more appropriate for backend engineer or technical lead.
  • 2 Offers