Failing Is Not Failure — What I Learned From Failed Interviews

#career #codenewbie #watercooler

Hello Fellow Codenewbies 👋,

Recently I had an(other) interview for a software engineer position. And as you can guess from the title of this post ... I failed 😅.
Having a chain of interviews and technical assignments is already soul-crushing.
And after several times failing? No sugar coat. I felt like a failure and very demotivated.

So I took some break from everything to reflect and regain strength.
After the breaks and some thoughts, I learned valuable things from these experiences.

You know more than you thought.

I often think that I don't know anything and am incapable. That maybe tech is not for me. Yes, imposter syndrome is real!

Take-home assignments and deadline submissions are different for each company.
So, you never know what kind of assignments you will get.

The funny thing is, sometimes, I could do something I had never thought of before. Or I found myself using some concepts I often couldn't wrap my head around to do the take-home assignments.

I still need to sharpen my skills, but now I have more self-confidence. Because, without realizing it, I know more than I thought.

Don't get discouraged by short deadline assignments.

Depending on the complexity of the projects, there might be times when you couldn't finish them within the timeline.

But don't let this be a discouragement. If it happened, tell the interviewer what you would add or do if you had more time and how you would do that. Walk them through your thinking process.

Take some notes.

Before the technical interview.

When you do the take-home assignment, you might want to take notes about the steps of what you did and the behaviors, especially if you refactor your code and fix some bugs.
Because sometimes, you can forget how and why you did something in the first place. These notes will be handy to look at during the interview process when you start to get lost.

In one of my experiences, I didn't have more time to fix some bugs and had to push whatever I had onto GitHub.
I got some time to wait for the company to call me back to schedule the technical interview.
During this time, I created another branch and made some fixes. I also went further with the assignment as much as possible while taking notes.

During the interview, the interviewer asked me why I decided to use some concepts and not something else. And what I would do to fix some bugs that arose. Because I've done the process and written them on my notes, I was more relaxed and confident in walking through my thinking process.
I showed them the fix on the other branch and what I could do if I had more time.
Luckily, I also had my notes ready. Because there was one point when I got anxious and got stuck. So I took a glimpse at my notes to get me on track.

If you are expected to push your assignment to GitHub, you can also write these things down on the README file. This way, you can give the interviewer some idea of your process in building the project before the interview.

What can you include in the README?

Description
- Short and clear description of the project and how it works.
- Frameworks and versions you use for the assignment.
- Live preview link (if any).
- Etc.
How to install the project
- Project installation steps.
How I work on this project
- Did you follow a design?
- What is your goal for the project within the timeline, and how did you do that?
- Etc.
Why I built the project this way
- Why do you use vanilla CSS instead of CSS frameworks?
- Why do you use v1 of a framework instead of v2?
- Etc.
If I had more time, I would change ...
- Fix the navbar styling.
- Refactor the codes in the form section.
- Improve accessibility.
- Etc.
If I had more time to do research, I would do ...
- Add authorization for the form.
- Add animation for the hamburger menu.
- Etc.

After each interview.

While it's still fresh, write down what questions were asked and how you answered them.
A list of questions can help you prepare to answer similar questions in the future.

Nothing personal.

This is something that I should also keep reminding myself of over and over again.
Have you ever heard someone did fantastic at a job interview and got rejected?
Or when someone blew an interview, but they got the job?
That's because there is nothing personal about interviews and rejections.

The hiring team needs to find someone who fits the whole team well. And they often have some strong candidates. I cannot say that I know what they are looking for or why they decide on one candidate over the other. But I can imagine it's not easy for them to choose between strong candidates.

So, if you ever get a call for an interview, you should be proud of yourself! That means you are one of the strong candidates; they see something in you and want to know you more! Congrats!

Feedback for self-improvement.

When you get rejected, don't be afraid to ask for feedback. A good company will answer and provide feedback for you.
Use this feedback to improve yourself and your skill for your next journey.

Conclusion

Failing is not a failure. Failing is growing.

Receiving rejections is hard for anyone. Take the break you need, then come back and push through. Learn something from every interview and be a better developer.

If you fail, never give up because F.A.I.L. means "First Attempt In Learning";
End is not the end. In fact, E.N.D. means "Effort Never Dies";
If you get no as an answer, remember: N.O. means "Next Opportunity";

— A.P.J. Abdul Kalam —

Thank you for reading!
Last but not least, you can find me on Twitter. Let's connect! 😊

📷 Cover photo by JESHOOTS.COM on Unsplash