The last week was kind of an important one for me. Because I had my first mock interview, which was aimed to test my knowledge in diverse tech topics in order to evaluate them. Alongside with this interview I'm currently reading the book Cracking the Coding Interview. So I think you get where this is going, this week was about interviews and more interviews.
I'm still waiting for my feedback to see my areas of improvement in this regard, but so far I've learned a few stuff thanks to the book and the material consumed. Here are some key points:
- It's okay to send up a follow email if you haven't heard from your recruiter in 3-5 bussines days
- No answer != rejected
- Big tech companies care more about accepting bad candidates that appear good (false-positive), than rejecting a good candidate that seems bad (false-negative)
- Being good at interviews is a skill of its own, you can be good at your job and bad at interviews
- They are really common in our industry so they're worth practicing when acquiring a new job
- Thinking out loud can really help your interviewer appreciate your thought process
- Before going to the brute force solution, try to figure out a more efficient solution
To be honest I'm still working on grasping this one, but of course I've made some progress!
- In our industry when we refer to Big O, we're actualy referring to Big Theta Θ (I'll just keep calling it Big O)
- Drop the constants, they don't make a big difference. i.e -> O(2N) it's practically the same as O(N)
- Drop the non-dominant terms. i.e -> O(N² + N) is the same as O(N²). Why should we care if O(2N²) is the same as O(N²)
- Binary search is a great example of the complexity time O(logN). You can appreciate this complexity when you cut the problem space in half each time. Like Binary Search does each time it cuts the array in half.