> The system will first get all userIDs of friends from friend table. Then it fetches all feedIDs for each friend from user-feed table. Finally, feed content is fetched based on feedID from feed table. You can see that we need to perform 3 joins, which can affect performance.
>
> A common optimization is to store feed content together with feedID in user-feed table so that we don’t need to join the feed table any more. This approach is called denormalization, which means by adding redundant data, we can optimize the read performance (reducing the number of joins).
> A common optimization is to store feed content together with feedID in user-feed table so that we don't need to join the feed table any more. This approach is called denormalization, which means by adding redundant data, we can optimize the read performance (reducing the number of joins).
>
> The disadvantages are obvious:
> - Data redundancy. We are storing redundant data, which occupies storage space (classic time-space trade-off).
> - Data consistency. Whenever we update a feed, we need to update both feed table and user-feed table. Otherwise, there is data inconsistency. This increases the complexity of the system.
> - Remember that there’s no one approach always better than the other (normalization vs denormalization). It’s a matter of whether you want to optimize for read or write.
> - Remember that there's no one approach always better than the other (normalization vs denormalization). It's a matter of whether you want to optimize for read or write.
@ -696,7 +696,7 @@ As a personal habit, I never leave my variables undeclared or unassigned. I will
### What is a closure, and how/why would you use one?
A closure is the combination of a function and the lexical environment within which that function was declared. The word "lexical" refers to the fact that lexical scoping uses the location where a variable is declared within the source code to determine where that variable is available. Closures are functions that have access to the outer (enclosing) function’s variables—scope chain even after the outer function has returned.
A closure is the combination of a function and the lexical environment within which that function was declared. The word "lexical" refers to the fact that lexical scoping uses the location where a variable is declared within the source code to determine where that variable is available. Closures are functions that have access to the outer (enclosing) function's variables—scope chain even after the outer function has returned.
**Why would you use one?**
@ -1154,7 +1154,7 @@ The downsides:
### What is the extent of your experience with Promises and/or their polyfills?
Possess working knowledge of it. A promise is an object that may produce a single value some time in the future: either a resolved value, or a reason that it’s not resolved (e.g., a network error occurred). A promise may be in one of 3 possible states: fulfilled, rejected, or pending. Promise users can attach callbacks to handle the fulfilled value or the reason for rejection.
Possess working knowledge of it. A promise is an object that may produce a single value some time in the future: either a resolved value, or a reason that it's not resolved (e.g., a network error occurred). A promise may be in one of 3 possible states: fulfilled, rejected, or pending. Promise users can attach callbacks to handle the fulfilled value or the reason for rejection.
Some common polyfills are `$.deferred`, Q and Bluebird but not all of them comply to the specification. ES2015 supports Promises out of the box and polyfills are typically not needed these days.
- **This** - The `this` keyword does not refer to the function in which it is used or it’s scope. It refers to the object on which a function is being executed and depends entirely on the call-site of the function.
- **This** - The `this` keyword does not refer to the function in which it is used or it's scope. It refers to the object on which a function is being executed and depends entirely on the call-site of the function.
Here are some psychological tricks that will help you ace a job interview.
- Tailor your answers to the interviewer’s age.
- Tailor your answers to the interviewer's age.
- Generation Y interviewers (between 20 and 30): Bring along visual samples of your work and highlight your ability to multitask.
- Generation X interviewers (between 30 and 50): Emphasize your creativity and mention how work/life balance contributes to your success.
- Baby Boomer interviewers (between 50 and 70): Show that you work hard and demonstrate respect for what they've achieved.
- Hold your palms open or steeple your hands.
- Find something in common with your interviewer.
- Mirror the interviewer’s body language.
- Mirror the interviewer's body language.
- Compliment the interviewer and the organization without self-promoting.
- Specifically, the students who ingratiated themselves praised the organization and indicated their enthusiasm for working there, and complimented the interviewer. They didn't play up the value of positive events they took credit for or take credit for positive events even if they weren’t solely responsible.
- Specifically, the students who ingratiated themselves praised the organization and indicated their enthusiasm for working there, and complimented the interviewer. They didn't play up the value of positive events they took credit for or take credit for positive events even if they weren't solely responsible.
- Show confidence and deference simultaneously.
- In a job interview, that means showing deference to your interviewer, while also demonstrating self-confidence. One way to do that is to say something like, "I love your work on [whatever area]. It reminds me of my work on [whatever area]."
- Emphasize how you took control of events in your previous jobs.
@ -13,7 +13,6 @@ Here are some good questions to ask at the end of the interview, extracted from
- What does a typical day look like for you?
- What do you think the company can improve at?
- How would you see yourself growing at this company in the next few years?
- What do you wish you were told about the company before you joined?
- Was there a time where you messed up and how was it handled?
- Why did you choose to come to this company?
- When you were last interviewing, what were some of your other options, and what made you choose this company?
@ -42,11 +41,11 @@ These questions are suitable for any technical role.
- How would you describe your engineering culture?
- How has your role changed since joining the company?
- What is your stack? What is the rationale for/story behind this specific stack?
- Do you tend to roll your own solutions more often or rely on third party tools? What’s the rationale in a specific case?
- Do you tend to roll your own solutions more often or rely on third party tools? What's the rationale in a specific case?
- How does the engineering team balance resources between feature requests and engineering maintenance?
- What do you measure? What are your most important product metrics?
- What does the company do to nurture and train its employees?
- How often have you moved teams? What made you join the team you’re on right now? If you wanted to move teams, what would need to happen?
- How often have you moved teams? What made you join the team you're on right now? If you wanted to move teams, what would need to happen?
### Management
@ -58,10 +57,10 @@ These questions are suitable for asking Engineering Managers, especially useful
- **What are the strengths and weaknesses of the current team? What is being done to improve upon the weaknesses?**
- How did you become a manager?
- How do your engineers know what to work on each day?
- What is your team’s biggest challenge right now?
- What is your team's biggest challenge right now?
- How do you measure individual performance?
- How often are 1:1s conducted?
- How’s the current team composition like?
- What is the current team composition like?
### Leadership
@ -93,4 +92,4 @@ These questions are intended for senior level management, such as CEO, CTO, VPs.
- [Questions I'm asking in interviews](http://jvns.ca/blog/2013/12/30/questions-im-asking-in-interviews/)
- [How to interview your interviewers](http://blog.alinelerner.com/how-to-interview-your-interviewers/)
- [How to Break Into the Tech Industry—a Guide to Job Hunting and Tech Interviews](https://haseebq.com/how-to-break-into-tech-job-hunting-and-interviews/)
- [A developer’s guide to interviewing](https://medium.freecodecamp.org/how-to-interview-as-a-developer-candidate-b666734f12dd)
- [A developer's guide to interviewing](https://medium.freecodecamp.org/how-to-interview-as-a-developer-candidate-b666734f12dd)
@ -25,7 +25,7 @@ Next, gain familiarity and mastery of the algorithms and data structures in your
1. Practice coding algorithms using your chosen language. While [Cracking the Coding Interview](http://www.crackingthecodinginterview.com/) is a good resource for practice, I prefer being able to type code, run it and get instant feedback. There are various Online Judges such as [LeetCode](https://leetcode.com/), [HackerRank](https://www.hackerrank.com/) and [CodeForces](http://codeforces.com/) for you to practice questions online and get used to the language. From experience, LeetCode questions are the most similar to the kind of questions being asked in interviews whereas HackerRank and CodeForces questions are more similar to competitive programming questions. If you practice enough LeetCode questions, there is a good chance that you would have seen/done your actual interview question (or some variant) on LeetCode before.
2. Learn and understand the time and space complexities of the common operations in your chosen language. For Python, this [page](https://wiki.python.org/moin/TimeComplexity) will come in handy. Also find out the underlying sorting algorithm that is being used in the language's `sort()` function and its time and space complexity (in Python its Timsort which is a hybrid sort). After completing a question on LeetCode, I usually add the time and space complexities of the written code as comments above the function body to remind myself to analyze the algorithm after I am done with the implementation.
3. Read up on the recommended coding style for your language and stick to it. If you have chosen Python, refer to the PEP 8 Style Guide. If you have chosen Java, refer to Google’s Java Style Guide.
3. Read up on the recommended coding style for your language and stick to it. If you have chosen Python, refer to the PEP 8 Style Guide. If you have chosen Java, refer to Google's Java Style Guide.
4. Find out and be familiar with the common pitfalls and caveats of the language. If you point out them out during the interview and intelligently avoid falling into them, you will usually impress the interviewer and that results in bonus points in your feedback, regardless of whether the interviewer is familiar with the language or not.
5. Gain a broad exposure to questions from various topics. In the second half of the article I mention algorithm topics and practice questions for each topic. Do around 100–200 LeetCode questions and you should be good.
@ -74,7 +74,7 @@ When you copy and paste code, consider whether it is necessary. Sometimes it is,
After you have finished coding, do not immediately announce to the interviewer that you are done. In most cases, your code is usually not perfect and contains some bugs or syntax errors. What you need to do now is to review your code.
Firstly, look through your code from start to finish as if it is the first time you are seeing it, as if it was written by someone else and you are trying to spot bugs in it. That’s exactly what your interviewer will be doing. Look through and fix any minor issues you may find.
Firstly, look through your code from start to finish as if it is the first time you are seeing it, as if it was written by someone else and you are trying to spot bugs in it. That's exactly what your interviewer will be doing. Look through and fix any minor issues you may find.
Next, come up with small test cases and step through the code (not your algorithm!) with those sample input. Interviewers like it when you read their mind and what they usually do after you have finished coding would be to get you to write tests. It is a huge plus if you write tests for your code even before prompts from them. You should be emulating a debugger when stepping through and jot down or say out the values of certain variables as you step through the lines of code.