Message on Whatsapp 8879355057 for DSA(OA + Interview) + Fullstack Dev Training + 1-1 Personalized Mentoring to get 10+LPA Job
0 like 0 dislike
1,702 views
in Advice/Suggestion/Opinion by | 1,702 views

5 Answers

0 like 0 dislike

Hi There,

First things first let me tell you, that the situation that you're facing is not new.

Not all people get the job in their very first attempt, and if they did, not many stick to it. In this age of cut-throat competition, each and every interview tests lot of depth in the field that they expect the candidate to be proficient in. After all they've to pay you for your time as well as all the resources they give, so the competition will be surely tougher as more and more coders add themselves into this competition.

There is a difference between writing up software and passing an interview. Writing software requires understanding and the ability to craft code. But Interview Preparation requires practice and knowledge on relatively few topics that get asked frequently, outsourced especially from sites such as GeeksforGeeks | A computer science portal for geeks. So even if you're not able to do well now in interviews, don't lose heart. Just understand that interview is more of a passport to get you that chance, like the screentest before you actually land a role in a movie. Just because you lose some movies at first, doesn't mean you can't act or doesn't mean you can't be in movies. Right?

Instead, focus on what I'm going to tell you now.


1. Treat each Interview as a QuestionBank. You really don't have to think whether it's a failure or a pass. Just think, about it as a test that just lets you evaluate yourself, and do take it as it is supposed to be. Understand the questions that were asked, write them down, think why you couldn't do that esp. the branch of coding that it's related to, such as Dynamic Programming or Recursion, which without proper understanding can't be solved easily in a pressure situation.

2. Passing interview is more about exposing yourselves to all the questions being actually asked. Have you really gone through the complete GeeksForGeeks website? No right? Do that first. It means that you will be exposed to all the different models in which a question is present, the type of answers and the approach to be taken. Learn the approach rather than the answer by rote. Then, you can apply this approach even if similar sounding questions come up.

3. Not all interviews and all companies have much tougher interviews. Some companies do have easier rounds upfront as they might've resource crunch at that particular time or have urgent positions to fill. If you don't make up your mind, you will miss these companies. So if survival is your priority, do keep attending interviews and one of these will turn up, eventually.

4. Become good at it, take a whiteboard and start coding on the board. Become comfortable with it. Refer to good books such as Cracking Coding Interview by GayleMcDowell.

5. Code code code. No substitute to this.


Finally just don't give up. You're in the right field, trust me. Make it count.

by
0 like 0 dislike

Suitability of being a Developer, can be judged by simple answers of Yes/No from the following:

  1. Do you get frustrated if you can't complete a task?
  2. Do you like solving problems?
  3. Do you get bored very easily while trying to solve an issue?
  4. Have you tried creatively (using non-book knowledge), to speed up the performance of an algorithm? (forget big-O for a second, most people don't even remember the notation values, just use single threaded performance calculated by milli-secs, time it from start to completion)
  5. Do you even like coding? (Did you become a programmer out of your own choice?)
  6. Do you like opening stuff (gadgets) just to see how it works, does curiosity drive you?
  7. Do you hate Math? (not a requirement but it tells you how you deal with problems out of your comfort zone)
by
0 like 0 dislike

There are countless number of companies you have never tried yet, let alone you can also start your own business.

But before you go for the next interview, I have some tips for you in terms of interview preparation.

1. Spend some time to summarize your past 8 interviews
It's extremely important to understand why you failed the past 8 interviews. Without realizing the real cause, it's very likely that you're gonna fail the next one.

As you said, your algorithm and data structure skills are weak, which is quite possible the reason. But I think it's still too general because coding interviews for new grads are usually focused on data structure and algorithm, so your summary is like I failed the interview because I didn't prepare well.

So let me help you nail down the cause. Majority of people failed coding interviews due to 2 reasons. First they are conceptually not familiar/clear about data structure and algorithm. Second they don't have enough practice with interview questions. If most of the time you couldn't figure out which data structure to use, or have problem when analyzing time/space complexity, or you don't fully understand pros and cons for each data structure (like comparing linked list with tree and when to use each of them), I would say you fall into the first category and you should really pick up your textbook to have better understanding of these basic knowledges.

However, if you are quite clear about each data structure and algorithm, but you were slow when solving those questions, or couldn't get to the optimal solution, it's likely that you just need more practice. I'll cover this in following sections.

2. Be familiar with coding questions
You should always spend enough time on coding questions. There are lots of online resources like leetcode.comglassdoor.com and Cracking the Coding Interview. Here are several thing to keep in mind:

  • It's always good to practice past interview questions from the company. It's unlikely to be asked the same question in real interview, but you can get an idea about the style and focus of that company.
  • Try to write down your solution on white board or at least on paper. Many candidate could jump to the write solution quickly, but failed to write down the code. It's so different between describe the solution and code the solution perfectly.
  • Try to talk while thinking. This is quite important in a real interview since you need to keep communicating with the interviewer. You may feel hard to focus initially and this requires some practice.


3. Have mock interview
Technical interview doesn't only evaluate your coding ability, but a variety of skills and abilities like communication skills, analysis ability etc.. Also many people will feel nervous solving a problem when someone is looking over his shoulder. That's why people may fail with problems that can be solved easily at home. The key point is to practice with a real person instead of yourself.

A lot of people also want to get good quality feedbacks from experienced interviewers. With that in mind, we worked on building Gainlo - Mock Interview with Professionals, which allows candidate have mock interview with experienced interviewers from top companies like Google, Amazon etc. and will get real feedback to help them improve. I think in your case, some real feedback about your performance is very important.

Conclusion
Failing few interviews in a row is not a big deal since you can have more interviews later. The point is really to understand why you failed those interviews and how to best prepare your next one.

by
0 like 0 dislike
Well, I failed to clear a lot more ......

First there was Cisco. Day One of placements, 50 candidates shortlisted. Interviews happening, and me continuing to be interviewed. Candidates were rejected. Additional ones were called, and yet, I persisted. My last interview for the day happened after 9:00 p.m., with the interviewer asking me, after the interview, whether I was someone else. That someone else, was then interviewed, and after 10:30 p.m., I did not get the job.

What followed next was EMC2. and it was the complete opposite. After being interviewed, I found out that a few other people got the job.

After that, came IBM, who realized that they did not have enough interviewers.

Then Thorogood.

Followed by NetApp, who were courteous to give me an interview at the end of the day.

Then I was called to Informatica for an interview process, which started out well, and went downhill from there.

eBay came and went, along with TCS and Infosys.

Then came citi, followed by the big one - Microsoft. Microsoft - Now that was an example of an opportunity missed. After making it out through 3 and a half rounds of interviews, a sudden implosion.

So, here was have 9 placements, saying NO, and it is only the odd semester...

Next was Mercedes - said No because it was an automobile company, rather than core software (Yes, there is such a thing).

After that, was Azul - the first written test that I failed to clear (because I did not know about the negative marks in the test).

What followed was a few interviews by a few start-ups, which I did not have much success with, all the way till May.

The first week of June had a lot of interviews.

On Monday, was Qualcomm's written test, followed by another start-up's interview. Neither one was converted.

Tuesday afternoon was the PhD interview at the Computer Science and Automation Department at IISc - which was a disaster, especially as I was using the morning to revise for it.

Wednesday morning was the PhD interview at the Supercomputer Education Research Centre at IISc, which went a little better. Wednesday afternoon was an interview with a PSU, called CSTEP. I soon got an offer from CSTEP.

On Thursday, I attended the Nokia interviews, and got an offer the following day. After the interview, I caught a bus to go for the Qualcomm interview, only to be told, after reaching the venue that Qualcomm "would no longer be pursuing the candidature of Sandeep Mathias".

So, if you failed 5 straight interviews, go for the 6th, and the 7th, and every other interview that comes along.
by
0 like 0 dislike

Technical interviewing is broken.

I have failed 9 interviews at the SAME company before getting hired there.

Thanks to help from “cracking the coding interview” and other books, we are now subject to regurgitating puzzles and quizzes given to CS students, which bare little or no resemblance to actual real-world problems we face every day.

These quizzes usually involve extremely low-level algorithms which we have libraries on top of as a developer, with syntactic sugars on top of those in order to make them more usable for us in our daily work routine.

Even worse, I’ve noticed that these interviews usually come down to a single, nuanced algorithm problem administered to the candidate - and will result in failure if complete, runnable code is not written on a whiteboard in less than a couple minutes.

So following this paradigm, a developer can have a huge wealth of experience behind them, a proven track record, positive references, and very strong algorithm and data structure skills - but if they fail a single algorithm, chosen out of thousands and thousands of algorithms, which - in turn - have possibly dozens or hundreds of different solutions and time complexities, their entire future at an organization is systematically eliminated.

A previous interview I had, for a front end developer - went something like this:

  • Interviewers enter room, write a “balanced delimiter” algorithm on white board, ask me to solve it. I solved the algorithm but only up to log (n) complexity, I couldn’t think of O(1) solution.
  • 99% of the rest of the 4 hour interview went amazing, and I went above-and-beyond their expectations in every category.
  • I remarked that I have most experience with NodeJS, and them being Objective C engineers, I wanted to make sure they knew we didn’t have Dictionary, Queue, Stacks in native javascript.
  • The interviewers during the algorithm portion, before leaving the room stated: “NodeJS is a bullshit language and anyone who writes it is not a real programmer” and slammed the door.

Needless to say I did not pass this interview. Everything I’ve done in the past, everything I’ve learned was ignored because of a single time complexity surrounding a single algorithm.

Technical interviewing is broken.

by