Meta Java Developer Interview Questions & Answers

At a high level, I would build a privacy-check API that decides which viewers may see a piece of content. The client sends POST /visibility/resolve through the API Gateway with the content ID, viewer IDs or a page token, and a JWT. The Java Spring Boot service validates the caller, checks a fresh cached decision, and otherwise loads the privacy rule, relationships, and allow or block lists. The Policy Engine evaluates visibility, with blocked users always denied. The main trade-off is speed versus freshness because caching reduces repeated work but requires a limited TTL.

The problem is to decide which people can see one piece of content. The answer depends on who owns the content, how that owner chose to share it, how each viewer is related to the owner, and whether any viewer appears on a special allow or block list. We also want this decision to be fast because a feed may perform many checks. The diagram solves this by verifying the caller, checking cached results, reading the required privacy information, applying the rules, returning the allowed viewers, and recording the decision.

• Do we need to check a supplied list of viewers, or resolve the audience page by page?
• Which privacy modes must we support?
• How fresh must relationship and block-list changes be?

I would expose POST /visibility/resolve through the API Gateway. The Client / Feed Service sends contentId, viewerIds[] or a page token, and a JWT over HTTPS. The API Gateway forwards that request into the Java Privacy Check API built with Spring Boot. The Controller receives the forwarded request and passes it to the Visibility Service. This keeps the HTTP entry point separate from the privacy decision logic.

The Visibility Service asks the Auth Service to validate the JWT and the caller's permissions. The Auth Service returns an auth result to the Java service. Authentication establishes who the caller is, while the permission check determines whether that caller may use this operation. If this validation fails, the Java service fails closed. It does not continue with an untrusted or unauthorized caller. This is the main security decision shown in the diagram.

The Visibility Service looks in the Audience Cache for a cached decision or audience page. The cache returns a hit or miss. A fresh hit can avoid repeating the more expensive privacy lookups and policy evaluation. If the needed result is not available, the service continues with the source data. The cache is not treated as permanent truth. Cached audiences are stored with a TTL, which means each entry has a limited lifetime before it must be recomputed.

On a cache miss, the Visibility Service reads the information needed for the decision. It asks the Content Metadata Store for the content owner and privacy rule. The store returns ownerId, rule, listId, and groupId. The service asks the Relationship Graph Service for each viewer's relationship to the owner, such as friend, follower, or friend-of-friend. It also reads the List & Blocklist Store, which returns custom-list members and blocked users. These are separate data sources because they own different parts of the privacy decision.

The Visibility Service sends the gathered information to the Policy Engine to evaluate the visibility rules. The supported examples are PUBLIC, FRIENDS, FRIENDS_OF_FRIENDS, CUSTOM_LIST, and ONLY_ME. The rule determines which viewers are eligible, while the block list acts as an overriding restriction. Blocked users are always denied. After resolving the audience, the result can be stored in the Audience Cache with a TTL so later checks can reuse it for a limited time.

The diagram uses a fail-closed approach. If authentication fails, access is not granted. If the Relationship Graph Service times out, the Visibility Service may use the Audience Cache only when the cached result is still fresh. If no fresh cached result exists, the service denies until the relationship can be checked again. This favors privacy correctness over availability. It may temporarily deny someone who should have access, but it avoids exposing private content when relationship information is uncertain.

The Java service sends a decision event to the Audit Log as a separate logging flow. The Audit Log does not control the business response. The Java service returns allowedViewerIds[] and nextPageToken to the API Gateway. The gateway then returns the 200 OK response to the Client / Feed Service. The main design trade-off is performance versus freshness. Caching reduces repeated relationship and list lookups, but privacy changes may not be reflected until the cached result expires.

The design keeps privacy logic in one Policy Engine instead of spreading rules across clients. The benefit is that every caller gets the same decision. Authentication and caller-permission validation happen before the privacy check, so an invalid caller cannot bypass the service. The Audience Cache improves performance because fresh decisions can be reused. The downside is freshness. A friendship, block, or privacy setting may change while an older cached result still exists. A limited TTL reduces that risk. The service also fails closed when important information is uncertain. If the relationship service times out, only a fresh cache entry may be used; otherwise access is denied. This is safer, but temporary dependency problems can reduce availability for valid viewers.

At a high level, I would make canSee(owner_id, viewer_id) the central privacy decision API. The Feed Service gets the viewer identity from the JWT, then asks the Java Privacy API for an ALLOW or DENY decision. The API first checks a short-lived Decision Cache. On a miss, it reads the owner’s privacy rule and the viewer’s social relationship, including blocks and list membership. If required data cannot be checked and there is no cache hit, it fails closed with DENY. The trade-off is extra lookups for correctness, reduced by caching.

This problem is about deciding whether one person may see another person’s content. The owner may share content with everyone, only friends, selected friends, or only themselves. We must also respect blocks and exception lists. The goal is to make one clear place responsible for that decision. The design should be fast because feeds need many checks, but it must not show private content by mistake. I will follow the diagram from the viewer request, through the privacy decision, and back to either the requested content or a denial.

• Do we need to support the exact privacy modes shown: PUBLIC, FRIENDS, FRIENDS_EXCEPT, SPECIFIC_FRIENDS, and ONLY_ME?
• Should a block or explicit deny override normal friend-based access?
• How fresh must privacy changes be before cached decisions become invalid?

The request first goes from the Viewer App to the Content / Feed Service. The diagram shows an HTTPS GET for the owner’s content with a JWT. The Feed Service derives viewer_id from that JWT and calls canSee(owner_id, viewer_id) on the Java Privacy API. This matters because the privacy decision should use the authenticated viewer identity rather than trusting an arbitrary viewer_id supplied by the client. The Feed Service waits for an ALLOW or DENY result before deciding whether to return the owner’s content.

The Java Privacy API first asks the Decision Cache for a cached decision. A cache hit returns the earlier ALLOW or DENY result and avoids the policy and social graph lookups. A cache miss means the API must calculate the decision again. After calculating a fresh decision, the API stores it in the Decision Cache with the short TTL shown in the diagram. The benefit is lower latency for repeated checks. The downside is that a cached answer may briefly be older than the latest privacy or relationship state.

On a cache miss, the Policy resolver asks the Privacy Rule Store + Post Metadata for the effective audience rule. The response contains the privacy mode shown in the diagram: PUBLIC, FRIENDS, FRIENDS_EXCEPT, SPECIFIC_FRIENDS, or ONLY_ME. This component owns the stored privacy rule and post metadata. The Java Privacy API still owns the final access decision. List membership and social relationship information are checked separately through the Social Graph Service.

The Java Privacy API asks the Social Graph Service for relationship, block status, and list membership. The service can return information such as self, friend, follower, blocked, allow-list, or deny-list. The Decision engine combines these facts with the effective privacy rule. A follower alone does not satisfy a FRIENDS rule because that rule requires a friend relationship. A blocked viewer or a viewer on the deny-list is denied before normal public or friend-based rules are considered.

The Decision engine follows the rule order shown in the diagram. First, if viewer_id equals owner_id, it returns ALLOW. Next, if the viewer is blocked or on the deny-list, it returns DENY. PUBLIC returns ALLOW. ONLY_ME is owner only. FRIENDS requires the viewer to be a friend. FRIENDS_EXCEPT requires a friend relationship and no deny exception. SPECIFIC_FRIENDS requires membership in the allow-list. If none of these rules allows access, the default result is DENY. This default-deny behavior prevents an unknown case from accidentally exposing private content.

The Java Privacy API returns ALLOW or DENY, with a reason, to the Content / Feed Service. If the result is ALLOW, the Feed Service asks the Content Store for the owner’s content. The Content Store sends the content back to the Feed Service. The Feed Service then returns 200 OK plus the content to the Viewer App. If the privacy result is DENY, the Feed Service returns 403 Forbidden instead. This keeps privacy evaluation separate from content storage and ensures the content is fetched only after authorization succeeds.

The Java Privacy API also sends an asynchronous decision event to the Audit Log. This is a side flow and does not control the business response. For dependency failures, the diagram uses a fail-closed rule. If the privacy rule lookup or social graph lookup fails and no cache hit exists, the API returns DENY. The main trade-off is availability versus privacy safety. A dependency outage can temporarily hide content from an allowed viewer, but the system avoids exposing content when it cannot confirm that access is permitted.

The benefit of this design is that one Java Privacy API owns the privacy decision. That keeps the privacy rules consistent for the Feed Service. The Decision Cache reduces repeated reads and improves latency when the same decisions are checked again. The downside is that cached decisions can become stale, so the diagram uses a short TTL. Reading both privacy data and social graph data gives the Decision engine the information it needs, but these dependency calls add latency. The design accepts that cost because privacy correctness is important. Failing closed is safer because missing rule or graph data cannot accidentally expose private content. The downside is lower availability during dependency failures. An allowed viewer may temporarily receive DENY until the required data becomes available again.

At a high level, I would keep post content separate from the privacy policy that controls who can see it. The client sends all three APIs through an API Gateway, which handles HTTPS, JWT authentication, and rate limiting. The Spring Boot application routes each request to the correct service. Privacy settings come from the User Privacy Settings DB, post content goes to the Posts DB, and effective privacy rules go to the Post Privacy Metadata DB. The trade-off is extra storage and service calls, but privacy checks stay clear and focused.

This question asks us to design three simple actions around Facebook post privacy. A user needs to read available privacy settings, create a post with a visibility rule, and check whether another person can view that post. The main challenge is keeping the post and its visibility information consistent while making checks easy and fast. I would follow the diagram by storing the message separately from its privacy information. Then the system can decide who may see a post without changing or rewriting the message itself.

• Which privacy rules must we support: public, friends, friends except, only me, and custom audiences?
• Should privacy checks use current friendship, block-list, and custom-audience information?
• Should post creation and privacy checks be recorded for analytics?

I would place the Facebook Web / Mobile Client in front of an API Gateway. Every request first reaches that gateway. It uses HTTPS for encrypted traffic, JWT authentication to identify the caller, and rate limiting to control request volume. The gateway forwards requests into the Java Application Boundary. That boundary contains the Spring Boot Privacy & Post API with three entry points: /get-privacy-settings, /post-message, and /check-privacy.

For GET /get-privacy-settings?userId=123, the client sends the request through the API Gateway. The gateway forwards it to /get-privacy-settings, which uses the Privacy Settings Service. That service reads default privacy choices and custom lists from the User Privacy Settings DB. If named friend lists must be resolved, it also uses the Social Graph Service. The response returns through the Java API and API Gateway to the client as 200 privacy settings.

For POST /post-message {authorId, message, privacyRule}, the gateway forwards the request to /post-message, which uses the Post Service. The Post Service asks the Privacy Settings Service to validate the privacy rule. It stores the post content in the Posts DB and stores the effective privacy policy in the Post Privacy Metadata DB. It also sends a post_created event to Audit Log / Analytics. The response returns through the gateway as 201 {postId, status}.

For GET /check-privacy?viewerId=456&postId=p789, the gateway forwards the request to /check-privacy, which uses the Access Evaluation Service. That service loads the privacy policy from the Post Privacy Metadata DB. It loads the owner ID and post state from the Posts DB. It also asks the Social Graph Service for friendship, block-list, or custom-audience information when needed. It evaluates PUBLIC, FRIENDS, FRIENDS_EXCEPT, ONLY_ME, or CUSTOM. It sends a privacy_check event to Audit Log / Analytics. The response returns as 200 {allowed: true|false, reason}.

Inside the Java application, the JPA / Repository Layer provides the data-access abstraction used by the services. The Posts DB owns post content and post state. The Post Privacy Metadata DB owns the effective visibility policy. The User Privacy Settings DB owns user defaults and custom lists. The Social Graph Service supplies relationship information. Audit Log / Analytics receives activity events and is not part of the business response path.

The main benefit is separation of responsibility. Privacy checks can read the stored policy without rewriting post content. The downside is more coordination because post creation writes content and privacy information separately, while access checks may read several sources. We accept that extra work because the privacy decision stays explicit and easier to reason about.

The main design choice is separating post content from privacy metadata. The benefit is that /check-privacy can read the visibility policy directly without changing the post. The downside is that /post-message must store two related pieces of information, so there is more coordination. Some privacy rules also need the Social Graph Service to check friendship, block lists, or custom audiences. That adds another dependency to the access path. HTTPS protects traffic, JWT authentication identifies the caller, and rate limiting controls request volume at the API Gateway. The JPA / Repository Layer keeps Java data access separate from business logic. Audit events improve visibility into post creation and privacy checks, but they add operational work. We accept these costs for clearer ownership and simpler policy evaluation.

At a high level, I would design this as an in-memory counting set, or multiset, inside one Java JVM. The API exposes add, remove, and count. A HashMap<T, Integer> stores the frequency of each value. add increments the count. remove decrements it and removes the key when the count reaches zero. count returns zero for a missing value. The main correctness rule is that the map stores only positive counts. This gives average O(1) operations, with O(n) space for n distinct values.

This problem asks us to keep track of how many copies of each value exist. A normal set only tells us whether a value exists. Here, adding the same value again should increase its number. Removing it should decrease that number. Asking for the count should return the current number. We want these operations to stay simple and fast. The diagram keeps everything inside one Java application and stores the values in memory. I would explain the same path from the caller, through CountingSet<T>, to the internal map and back.

• Should add and remove return the new count, as shown here?
• Should removing a missing value leave the state unchanged and return 0?
• Is this structure required only inside one JVM?
• Do we need thread-safe behavior for concurrent callers?

I would start by saying this is a counting set, also called a multiset or bag. Unlike a normal set, it keeps a frequency for each value, so duplicates are allowed. The CountingSet<T> API exposes three operations: add(T value): int, remove(T value): int, and count(T value): int. The Client / Caller sends one of these requests to CountingSet<T>. The API performs the operation and sends the new count or current count back as a separate response. This gives callers one small and clear contract.

Inside the Java Application, which is one JVM in the diagram, I would use HashMap<T, Integer> counts as the backing storage. The key is the value being tracked. The integer is its frequency. For example, a state can contain apple with count 2 and banana with count 1. The main invariant is simple: the map stores only positive counts. An absent key means count 0. We never keep zero or negative values in the map.

For add(value), CountingSet reads oldCount using counts.getOrDefault(value, 0). If the key does not exist, oldCount is

1. It calculates newCount = oldCount +
2. Then it stores counts.put(value, newCount). Finally, it returns newCount to the caller. For example, if apple currently has count 2, add(apple) stores 3 and returns 3.

For remove(value), the API first reads oldCount using counts.getOrDefault(value, 0). If oldCount is 0, the value is already absent. The state stays unchanged and remove returns 0. If oldCount is 1, removing one occurrence makes the logical count 0. The API removes the key from the HashMap and returns 0. If oldCount is greater than 1, it stores oldCount - 1 and returns that new count. These checks prevent zero or negative counts from remaining in the backing map.

For count(value), the API reads counts.getOrDefault(value, 0) and returns that value. It does not modify the map. This makes missing values easy to handle because an absent key naturally produces 0. The response then goes from CountingSet<T> back to the Client / Caller as the current count.

HashMap lookup, insertion, update, and removal are average O(1), so add, remove, and count are average O(1). Space is O(n), where n is the number of distinct values with positive counts. The benefit is that this design is small and fast for an in-process data structure. The trade-off is that the state lives in one JVM heap. Threads in that JVM can access the same object, but a different JVM or replica would not automatically share the same counts. The diagram intentionally does not add a database, cache, network service, or distributed coordination layer.

The benefit of this design is that each operation is simple and fast. HashMap gives average O(1) lookup, insert, update, and removal, so add, remove, and count also take average O(1) time. Space is O(n), where n is the number of distinct values with positive counts. Removing a key when its count reaches zero avoids keeping useless entries. The downside is that the HashMap lives inside one Java JVM. That is perfect for an in-memory data structure, but separate JVMs would not share the same state automatically. Another choice is returning the resulting count from add and remove. This is convenient for callers, but it makes the API contract more specific than simply returning success or failure.

At a high level, I would expose one GET endpoint that looks up a user ID and always returns a list for valid input. The API Client calls GET /users/{userId}/items. The GET Endpoint / Controller validates the userId, then calls UserListService. The service uses InMemoryUserListStore with map.getOrDefault(userId, emptyList). An existing key returns its List<String>, while a missing key returns 200 OK with an empty list. Invalid input returns 400 Bad Request. The benefit is a predictable contract. The trade-off is that the data is only stored in application memory.

This question asks us to build a very small way to find items for one user. A caller gives us a user ID. We check that the ID is usable, look for that user in stored data, and return the user's items as a list. If the user has no entry in the stored map, we still return a successful answer with an empty list. If the ID itself is bad, we reject the request. The diagram keeps this design simple by separating request handling, lookup rules, and the in-memory user data.

• Should a missing userId return an empty list or an error?
• Is an in-memory map enough for this exercise?
• What formats should count as a valid userId?

I would start with one simple read endpoint. The API Client sends HTTP GET /users/{userId}/items to the GET Endpoint / Controller. The userId comes from the path. The diagram does not show a request body. For a valid request, the API returns a JSON response containing the user ID and an items list. For example, user u100 returns {"userId":"u100","items":["itemA","itemB"]} with 200 OK. This gives the client a simple list-return contract.

The GET Endpoint / Controller owns path parsing, input validation, and the HTTP status. It reads the {userId} path parameter and checks whether the value is blank or malformed. If the value is invalid, the controller returns 400 Bad Request. The request does not continue to the service. If the userId is valid, the controller calls getItems(userId) on UserListService. This keeps HTTP input handling in the controller instead of mixing it with the lookup rule.

UserListService owns the lookup behavior and the default empty-list policy. After receiving a valid userId, it asks InMemoryUserListStore for the user's list using map.getOrDefault(userId, emptyList). This is the important design decision. A missing key does not become an error. It becomes an empty list. The service therefore gives the controller a predictable response payload for every valid userId.

InMemoryUserListStore owns the keyed in-memory user data. The diagram uses HashMap<String, List<String>>. The key is a userId such as u100. The value is a List<String>, such as ["itemA", "itemB"]. Another example is u200, which maps to ["itemC"]. For an existing key, the store returns its List<String> to UserListService. If the key is absent, the lookup follows the empty-list policy and returns an empty list.

The response travels back through the components in reverse order. InMemoryUserListStore returns List<String> to UserListService. The service returns the DTO or response payload to the GET Endpoint / Controller. The controller then sends the JSON response back to the API Client. A normal lookup returns 200 OK with the stored items. A userId not present in the map also returns 200 OK, but with items: []. A blank or malformed userId returns 400 Bad Request. The benefit is a simple and consistent API. The main trade-off is that the HashMap is in memory, so this diagram does not provide durable shared storage.