I've recently been laid off. If I were on my own, I would spend a year or two working on my ventures, living off my savings. But then, I had a commitment to buy a house for my parents soon, I'm not willing to “default” on that.

I'm going to find a balance between the two. That means looking for a job, where I can still learn about SaaS, about software, improve my skills which I can use later for the ventures.

It looks like a compromise, but maybe it's actually not. It's the shortest path forward, for me.

If a scope annotation is present, the injector may retain the instance for possible reuse in a later injection.

@SomeScope
@Component(dependencies = SomeModule.class)
interface SomeComponent {}

@Module
class SomeModule {
  @SomeScope
  SomeObject createObject();
}

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 {}

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.

Read more: Planning an Approach to a Topcoder Problem, Part 1

For Facebook, I should have thought and explained more critically.

I will try again in 2018.