Given the @Scope-annotated Dagger component above, the effect of @SomeScope is that, for the lifetime of SomeComponent, there will be one and only one SomeObject instance.
In other words, @SomeScope can be used to instruct SomeComponent to keep the SomeObject for later use.
How Is @Scope Implemented?
Under the hood, the DoubleCheck class is used internally to keep the object reference and re-inject it when requested.
If we remove the thread-safety-related code, it looks like this:
public final class DoubleCheck<T> {
private static final Object UNINITIALIZED = new Object();
private volatile Provider<T> provider;
private volatile Object instance = UNINITIALIZED;
@Override
public T get() {
if (instance == UNINITIALIZED) {
instance = provider.get();
}
return (T) instance;
}
}
From the code above, multiple calls to DoubleCheck.get() will return the same instance, which serves the purpose of scoped injection.
Android Example
In Android, an @ActivityScope declared as follows is often used to ensure that the scoped object is a singleton within the lifecycle of the activity, given that there is only one Dagger component associated with that activity.
@Scope
@Retention(RetentionPolicy.RUNTIME)
public @interface ActivityScope {}
The application and phone screen steps were the usual ones. They are available on other channels, such as Glassdoor and blog posts. In this post, I will only talk about the things specific to my onsite interviews and the things I could have done better.
Metadata
I interviewed with Google Sydney in November 2017 and Facebook Singapore in December 2017.
Both interviews were for Android engineer positions.
I failed both.
My Preparation
6.006 course from MIT on YouTube, about twice for each lecture.
Code Jam 2017. I could not get to round 2.
Kick Start 2017. My best rank was 239 in round C.
HackerRank and LeetCode, about 200 problems, with only a few hard problems.
Cracking the Coding Interview. I did most of the problems, with only a couple of problems from the hard section.
The Onsite
My Google onsite consisted of 5 coding interviews on a single day. They were heavy on algorithms and data structures. The questions were around hard difficulty on LeetCode. Usually, each interview started with a warmup question, around medium difficulty, then got more difficult as I solved them.
Facebook asked not only coding questions, but also system design and behavioral questions. The questions were relatively easier. I did give correct solutions, but that was not enough. I should have shown how I arrived at the solution. My recruiter suggested that I work on algorithms and data structures, so I guess that was the reason for rejection.
Why I Could Have Done Better
For Google, I should have solved more hard problems. Do not fall into the trap of pattern matching, especially for ad-hoc problems. The key is to strengthen problem-solving skill, not study the kinds or categories of problems and then pattern match them.