don't take rejections personally. They aren't rejecting you. They are rejecting you-for-this-position-at-this-time. And they may reject you even if you pass all

don't take rejections personally. They aren't rejecting you. They are rejecting you-for-this-position-at-this-time. And they may reject you even if you pass all of their paper requirements if they aren't sure you are a "superstar" because there is implied risk in hiring someone that doesn't fit "perfectly" and isn't ready to commit code to production on the first afternoon. Remember that interviewing is both a negotiation and is highly subjective. If you do well, but aren't a great fit for the open req, you may find a new req is created for you. Follow up with HR if you get rejected for a position to see if there are any other positions that might be a good fit. Ask HR if they have any constructive criticism from the interviews. Some interviewers will suck. Walk it off. I've been berated and given backhanded compliments by interviewers. You need to evaluate what you did in the interview and what you could have done better. Sometimes your effort will simply not make a difference -- you will need to learn to accept that. A mentor in the industry and your college employment office should be able to help you hone these skills and develop some new soft skills (the things that employers look for but don't show up as line items on resumes). Sometimes you just need confidence and you can get that by practice. Nobody likes rejections, but at least they come with practice. Ask your interviewer what you could have done better. You may not get a satisfactory answer (interviewers and companies may create liabilities or violate policies by answering those kinds of questions), but it can't hurt to ask. I will spend a little more time than most interviewers to try and coax out anecdotes which show initiative and grit. These don't necessarily have to be coding related -- they are attributes of people, not only of coders. If those anecdotes aren't prepared by the interviewer, I politely suggest that those things are great to open with. Programming is largely about learning on the job and less about memorizing APIs. I want someone who truly wants to work at the same company (is at least somewhat passionate about what we do), wants to row in mostly the same direction (or at least get to the same destination), who is humble enough to want to improve their skills, and who takes the initiative to fix issues before they become problems. If you can improve your next interview by learning from a previous mistake, do it. Certainly brush up on data structures and algos before you interview. This will require knowing which one to use in a given scenario. If you interview for a Python position, know how the language compares+contrasts to languages you know. Spend at least a little time rewriting code into Python. Open the REPL and play around. Look at Rosetta Code[1] to compare a chunk of code in a language you know and your target language. Do some "code golf" (see HackerRank section) in the new language. When you code on websites like HackerRank, make sure you iterate. Just because you completed a task doesn't mean that's an optimal way to solve it. Revisit tasks you have solved and try to optimize them. Try to find out how others have optimized them. [1] http://rosettacode.org/wiki/Rosetta_Code http://rosettacode.org/wiki/Rosetta_Code