How do I become a serious developer?

Hello everyone,

This really bothers me for some time and I need your help. I am an experienced developer, with 4 years of experience, I built apps and I am far from that level where I used to copy other people code. I can build most things myself and I understand how software architecture works.

But lately I am coming into job interview problems and I realised that I am not that good. On interviews they set these really hard algorithmic tasks that I never face in real life when I am working for a client on the app. Last few days I failed a programming interview even though I know they could benefit from my overall skillset. Keep in mind that I worked all my life alone (there are no Unity developers around me, I live in a small place) and I do not have benefits of working with other programmers where we would naturally share our experience.

Honestly I am bad at math and I always been, so I am naturally bad at algorithmic problems. As I started to create some custom generated things I started to understand how math is needed here. But I do not mind learning it. Could someone help me on where I could start? Do I need to understand algebra? I am really eager to learn and I am sick of being an average programmer, I really want to up my level!

 

Your title says "how do I become a serious developer" but your question reads more like "how do I get better at coding interviews". I'll answer the latter: Practice!

Here's a great long list of "interview" style questions: https://www.geeksforgeeks.org/practice-for-cracking-any-coding-interview/#hashing Maybe do a few of these every day. Most interview questions can be decomposed into one of only a few common programming paradigms. Not close to an exhaustive list but these are things like

• recursion
• dynamic programming
• graph/tree problems
• stacks and/or queues
• etc...

I've interviewed dozens of programming candidates and they generally fail for one of two primary reasons.

The first reason is that they can't code their way out of a paper bag. These candidates struggle with properly forming loops and the basic structure of their code.

The other group of candidates that fail can code just fine. Their problem is often that they simply fail to get that "aha" moment where they realize what the problem actually breaks down into. Sometimes this just happens.. But you can reduce the chance of this happening by doing lots of interview practice. You'll start to get a feel for the questions and you'll be able to quickly say "Oh this looks like a graph problem", or "Ok, this problem can be resolved with a LIFO queue".

Also one great skill to have: figure out how to write non-recursive versions of recursive solutions. Any recursive solution can typically be rewritten using a stack (a.k.a LIFO queue), since recursion is just an abuse of the intrinsic "call stack" structure of most programming languages. Lots of interviewers will ask you a recursion problem and then ask you to do it without recursion.

 

Honestly, you're probably already capable enough as you are, especially if you've already worked with clients and published some projects. It's just that programming job interviews are notorious for asking people to write some algorithm for a very specific and obscure problem that you're never going to run into on the job, and this is probably one of the reasons why there's so many people who go through "impostor syndrome" in this field.

Ask any mobile or web app developer how many complex algorithms they've written on the job, and I'd bet all of them would answer "zero". Pretty much any use-case requiring some sort of complex algorithm nowadays has already been written and is included within the standard libraries of every development framework.
If you ever actually need to rewrite an algorithm, you wouldn't do it from scratch, you would use the plenty of existing resources online as references, because these things have gone through years of refinement and documentation, and expecting someone to just write an algorithm within the next 20 minutes or so of the interview is unrealistic.

I could keep going on a long rant about the system, but this video pretty much sums up my thoughts on it:

 

Hey,

I know my reply here is super early but couldn't help myself from not commenting

But curious to know your programming journey since then.

Your statement:"I am really eager to learn and I am sick of being an average programmer"

Talking of my personal experience, there is no one programmer that I have come across so far is a "know it all" type of programmer. But one thing even if they know, they would go their way to try out different approaches to a problem.

One tip which I've learnt from seniors especially when given a problem, always be vocal about the approach you're taking to a problem. Many times interviewers anlayse that when making a selection and also at times help you break the problem down for you to be able to solve it at more ease.

- Also IMO, you need to be consistent with practising DS and Algo concepts:
https://www.interviewbit.com/courses/programming/
- Join communities and actively share your doubts.

 

Relationship building is also an important skill. In some cases, more important than raw technical knowledge.

Meet other developers, any way you can. Talk to them. Most important, ask good questions and listen to them. Especially, talk to people who work at companies you would like to work at. And focus on the work, not on money. Money will come with experience.

Learn about the culture and values of prospective employers: the companies and their leadership. If you make strong connections with people, and they know and trust you, you can reduce the impact of the interview process. Strong connections start as weak connections. Build a network.

If you want to get recognition for purely technical knowlege, then, yes, theory—including math—is absolutely necessary. Also, you will have to find ways to demonstrate your knowledge in such a way that you will attract good feedback. You have to share your talent and creative output, whether with open source code, demos, blog posts, participation on community websites or Discord, or building real working games that people want to play (or apps that they want to use for other things).

The only real proof of your ability is what you can build that is new, innovative, and valuable to others.

 

Coding interviews are IMHO essential and fine, but as part of a process in deciding on the candidate's skills. It's not that coding interviews are bad, only if they are the only reason someone is hired or not.

So the problem isn't the coding interview, it's the interviewer. It should just be one part of many factors in hiring someone.

For example you see someone with 5 years of HGV operations? You still want to see them drive one before hiring them.

In this case the coding interview should be used to determine the candidate's thought process, how they reason, things like that. If it's abused to be a yes/no, then it's just bad interviewing.

 

I improved a lot since I made the post. I realised that I studied programming the wrong way. Before I was creating things, but I didn't understand how they worked in the background, what data structures they use or algorithms. Now when I write code I understand exactly what I do. I studied data structures, algorithms and design patterns since.

I am doing those leetcode challenges all the time and I improve constantly. Web developers on average don't need deep knowledge in these things, but we as game developers we have to know, because our games have to be optimized and knowing when to use a certain algorithm or data structure is essential. And I did not only improve in programming, but now I feel like a different person, I feel way smarter overall, even when solving some real life issues. Now I can pass most game dev interviews, of course I am not on FAANG level, but I am good enough to be hireable by most companies.

The reason why I studied programming the wrong way was because I did it all on my own, I didn't talk to other developers. The failed interviews experience pushed me forward to realise that I was doing something wrong and that I needed to improve. Also I learned that I was not that good back then as I thought I was and it was the hardest pill to swallow for me. But I did improve quickly because I had the base knowledge, I just needed to learn things on a deeper level.

 

Excellent realization! This is covered in Step #2 of my "standard tutorial blurb" that I have posted a zillion times here. It is what separates people like you and I from those who don't make progress.

This is the blurb, FYI:

Tutorials and example code are great, but keep this in mind to maximize your success and minimize your frustration:

How to do tutorials properly, two (2) simple steps to success:

Step 1. Follow the tutorial and do every single step of the tutorial 100% precisely the way it is shown. Even the slightest deviation (even a single character!) generally ends in disaster. That's how software engineering works. Every step must be taken, every single letter must be spelled, capitalized, punctuated and spaced (or not spaced) properly, literally NOTHING can be omitted or skipped.

Fortunately this is the easiest part to get right: Be a robot. Don't make any mistakes.
BE PERFECT IN EVERYTHING YOU DO HERE!!

If you get any errors, learn how to read the error code and fix your error. Google is your friend here. Do NOT continue until you fix your error. Your error will probably be somewhere near the parenthesis numbers (line and character position) in the file. It is almost CERTAINLY your typo causing the error, so look again and fix it.

Step 2. Go back and work through every part of the tutorial again, and this time explain it to your doggie. See how I am doing that in my avatar picture? If you have no dog, explain it to your house plant. If you are unable to explain any part of it, STOP. DO NOT PROCEED. Now go learn how that part works. Read the documentation on the functions involved. Go back to the tutorial and try to figure out WHY they did that. This is the part that takes a LOT of time when you are new. It might take days or weeks to work through a single 5-minute tutorial. Stick with it. You will learn.

Step 2 is the part everybody seems to miss. Without Step 2 you are simply a code-typing monkey and outside of the specific tutorial you did, you will be completely lost. If you want to learn, you MUST do Step 2.

Of course, all this presupposes no errors in the tutorial. For certain tutorial makers (like Unity, Brackeys, Imphenzia, Sebastian Lague) this is usually the case. For some other less-well-known content creators, this is less true. Read the comments on the video: did anyone have issues like you did? If there's an error, you will NEVER be the first guy to find it.

Beyond that, Step 3, 4, 5 and 6 become easy because you already understand!