100% of 1 Students
Preparing for an internship is a few parts:
- Recognize what companies want
- Getting that (from classes, tutorials, lessons, practice)
- Showing them you've gotten that.
Regarding #1 (What companies want). It's easy to read a job listing and to be daunted because companies WANT everything. But, realistically, they want someone "good enough". Specifically, here are some key elements that are often overlooked:
- Can you take instruction? If you're going down the wrong path, are you able to take the hint that you should back up and explore another option, or do you get stuck in what you're trying to do?
- Will you communicate when you're in trouble? Many students keep doubling down on the idea that if they try hard enough it will work out, possibly at the last minute. Workplaces love for you to work, but they also want time to deal with the inevitable issues. Mentioning when you are stuck, or even just slowed down, as soon as you can gives them a chance to adjust resources and expectations. Learning that it's not only okay, but often DESIRABLE, to admit you had/have a problem is a hard lesson to learn, and harder still to confess your willingness to during an interview - but many places will want to hear that.
- That said, most of coding is dealing with new problems, so Googling for solutions and figuring out how to extract the meaningful bits from a post where someone dealt with the problem in an unrelated tech stack is a skill that classes rarely teach. MANY interviews will focus on behavioral questions like "Tell me about a time you were stuck on a mysterious problem and how you solved it" - having experience outside of class projects (where you encounter such problems) make these questions far easier to answer well, and build the skills you'll use on the job.
- The reason for the data structures and algorithm questions so many technical interviews include is not to see if you can solve that problem - it's to see if you can break a problem down into solvable pieces. If you can understand how to look at a problem and determine the right approach. Rarely will you be told on the job "solve this with a binary search tree" - you'll have some data and need to alter/search that data, and you need to be able to recognize the difference between a good way to do it and a bad way.
- Interviewers WILL ask you questions you won't know the answer to. If you knew all the answers to their questions, they'd make harder questions on the spot. This is because seeing how you handle the unknown is part of the point.
Moving to #2: Getting these skills
- I recommend HIGHLY working on projects outside of class projects (or extend projects you have to do new things). Get a github or gitlab account and put your code there. Add new features. maintain versions with a changelog listing the changes and improvements. You'll be solving the very problems you'll need as an intern, building the skills, and getting a nice addition to your resume. The project doesn't need to be fancy - in fact, I recommend with something stupidly basic that you slowly add to. Working on open-source projects that exist is a common recommendation, but I find that usually requires too much in-depth understanding of the existing code - instead, write your own projects. Make stupid mistakes, learn from them, and improve. Don't worry about this hurting your chances - making mistakes and learning from them demonstrates WAY more that an employer will want than a single pristine but unremarkable commit.
- There are definitely algorithm and data structure interview questions out there that you should practice for, but don't neglect coming from the other side: having a problem and breaking them down into code. You don't even need to code each of these, but make a practice to think "How would I organize a program to handle this problem?" When you're in line at the movies, think about how you'd manage their displays of menu items in the concessions line. How you'd write the software to manage tickets. How you'd write a scheduling program for workers.
And now, #3, Demonstrating these skills
- Remember that github/gitlab repo I mentioned you should do for a project? Make it. Make it public. Update it regularly. Put it on your resume. Be prepared to talk about that project, in particular where it gave you problems and how you eventually overcame them (or if you didn't, what you plan to do in the future about that.) . Remember: Companies don't want to hear you're brilliant and perfect. They know you AREN'T perfect, and want to see that you can regularly improve without guidance, and will improve even more WITH guidance.
- This sounds hokey, but I recommend you practice, out-loud, saying "I don't know". You want to make it almost habitual, muscle memory. This way when it happens in an interview you don't ratchet up your nervousness and anxiety and instead can apply your thinking power to looking good. Being nervous in an interview is totally normal - if you didn't have something at risk (getting a job you want) then it'd mean you weren't trying very hard. But nervousness can tank your chances, can disguise your value. So physically practice, so your instinct can happen without thought. Skim headlines and articles from sites like Hacker News (http://news.ycombinator.com) and pretend you are being asked questions about some technical bit in an article you don't know. (no one knows ALL the tech discussed there) "Websockets with IoT? I'm not familiar with that, can you explain a bit more?". Practice adding a guess, or countering with a question. Show that not knowing means you have interest and willingness, rather than cutting things off or that you bluster and pretend. Connect to something you do know. "I've not used a separate database cache layer, is that like a web CDN?"
And lastly, the 4th part: Expect some failure. Interviewing is something we're all (humans) bad at - not just as interviewees, but also companies are still trying to figure out how to identify what they want and then how to identify which people match that. You can bomb 6 interviews in a row and be exactly what the 7th wants, even if your performance in all 7 is the same. One place will give you a massive Hackerrank interview while another has a discussion that involves no or almost-no coding.
Brett recommends the following next steps:
- Work on a personal project
- Put your personal project on github/gitlab as a publicly visible repo
- Regularly update/add to that project. Solve real problems with it that make you struggle.
- Practice ways of saying "I don't know"
- Practice thinking how to model various real-world situations in code. Actually write some of them.
100% of 1 Students