Tackling off campus placements
- Programming Language
- Programming Language checklist
- Programming Best Practices Checklist
- Interview checklist
- INSIGHTS FROM FRIENDS:
IntroductionThis 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 LanguageLearn 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 checklist1. Primitive data types and their usage (Other languages could include many more)
- - Int, Float, String, Bool
- - Arrays, Dynamic arrays/SLICES?
- - Maps/Dictionary
2. Composite data types: structs
3. Functions for primitive data types:
- - Types conversions: eg. int -> string / string -> int
- - Traversing through the data structure: eg. Iterators (C++)
4. Learn how to use standard libraries your programming language provides. [ABSOLUTE MUST].
- Eg. C++ : vector, string, algorithm, hash map, list, queue, stack, dequeue, sets.
“I’ll create my own library” is the wrong way of solving the problem.
Programming Best Practices Checklist[WIP]
- - Recursion vs Memory/Memoization
- - Call by value vs Call by reference
- - Sensible variable naming conventions
- - ...
“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.
CodingLearn 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.
TechnologyMaster at least ONE implementation/framework for each of these:
- Legacy : C++, Java
- Relational Database: MySQL, PostgreSQL
- Non-relational Database: MongoDB
- Frontend framework: React / Angular
- Backend framework: Express-Node, Golang, PHP
- Web technologies: HTML+CSS+JS/TS
- Scripting languages: Bash, Python
- [OPTIONAL] : Containers , Docker , AWS / Azure
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.
InterviewI 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.
- Crude solution and it’s complexity
- Come up with good test cases that could include corner cases and exceptions
- Optimise your solution and give its complexity. Explain why it is better.
- Daily Coding Problems
INSIGHTS FROM FRIENDS:
- “They need to have projects—Good credible projects. An end to end one would be good.They show you understand the language/framework very well. Also, group ones are better.They show you can collaborate in a team well. ” - @realradone
- “First thing someone should know: their CV” - @realradone
- “For the Product IT ones-
- - Apply
- - Tell people on LinkedIn to give referral “ - @realradone
- “Read through JD's and Terms”