Tackling off campus placements

Introduction

This blog is a work in progress.
The following blog post is my personal experience with product development companies and their requirements. If you wanna find out more about applying to various domains like Machine/Deep learning , DevOps or others please contact devs from other domains.

Programming Language

Learn ONE programming language. And learn it all the way. So much so that you could/should create your own piece of software/tool. (Like I wrote Mizi)

Programming Language checklist

1. Primitive data types and their usage (Other languages could include many more)

2. Composite data types: structs

3. Functions for primitive data types:

4. Learn how to use standard libraries your programming language provides. [ABSOLUTE MUST].
Understand that these are abstractions for ADTs and could be implemented however you want.
“I’ll create my own library” is the wrong way of solving the problem.

Programming Best Practices Checklist

[WIP]

“Dude I like python. I absolutely hate C++”. If you’re this guy, ENSURE that you understand C++ inside out and then shrug it off simply because it doesn’t suit you.

Coding

Learn OOPS concepts. You have to. Object oriented approach is closest you could get to the real world. Every language has different ways of including oops concepts.
Writing badly structured and C-like procedural code is simpler but inconvenient — (Trust me I’ve been writing that sort of bad code earlier and it sucked ass)
Learn about time complexities. Whenever you come up with a solution, analyse it’s best case and worst case time complexities.

Technology

Master at least ONE implementation/framework for each of these:

Keep in mind that the company doesn’t expect you to know the best/latest/popular things out there. They expect you to have a good understanding of the concepts around it.

If your company uses legacy PHP — You’ll have to work on it regardless of your liking since that’s how the architecture was decades ago. If they use Serverless or say - AWS services you’ll be expected to get familiar with these.

Interview

I highly recommend you practice for coding rounds via Cracking the coding interview (CTCI). The typical flow should be trying to solve a problem on paper and then solving the same question on LEETCODE.

Go through every CTCI solution after you solve them. Most of the times there are multiple solutions for the same problem. The key is to understand WHY a particular solution is better.

While giving an interview, the interviewer focuses more on your approach to solve the problem— they don’t expect you to get to the best solution right away. As you read into the solutions for CTCI you’d discover the flow of solving interview questions:
1. Do not dive into coding straight away. That’s a red flag. Discuss the solution with your interviewer before you write any code.
3. Give a crude solution to the problem - whatever is at the top of your head. The interviewer will take your solution and point out some flaws which you might need to resolve. Once the interviewer is satisfied with your solution, they’ll most likely ask for the time complexity of your solution and how could you optimise it.
4. Try to optimise your solution with your data structures and algorithm knowledge.
5. Look out for corner cases and exceptions.
6. Write a few good test cases and do a dry run by trying to go through the code against on of the test cases.

Interview checklist


Resources


INSIGHTS FROM FRIENDS: