Requirements

Imagine you're building a "Stock Wizard" application for Google Finance. This wizard allows users to create complex, multi-step stock analysis workflows. The user can define a series of operations to perform on a stock, in a specific order. Each operation takes the stock data as input and produces an output (which could be another stock data point or a boolean signal for trading). A workflow can include operations like calculating moving averages, relative strength index (RSI), applying filters based on price or volume, and even executing trades (simulated, of course!). The core challenge here is designing a flexible and extensible system that can accommodate a growing number of operations and complex workflows, while also ensuring thread safety and efficient execution. We need to think about how to represent stocks, operations, workflows, and the execution engine that ties it all together. The design should be adaptable to new analysis techniques and integration with different data sources. # Requirements ## Functional Requirements 1. **Stock Representation:** Model a `Stock` entity with attributes like ticker symbol, timestamped price data (open, high, low, close, volume). The price data should be stored efficiently and allow for historical lookups. 2. **Operations:** Define a set of core `Operation` types: * `MovingAverage`: Calculates the moving average of a stock's closing price over a specified period. * `RelativeStrengthIndex (RSI)`: Calculates the RSI for a given stock and period. * `PriceFilter`: Filters stocks based on a price range (e.g., only include stocks with a closing price between \$100 and \$200). * `VolumeFilter`: Filters stocks based on volume (e.g., only include stocks with a volume greater than 1 million shares). * `TradingSignal`: Generates a buy/sell signal based on specified conditions (e.g., buy if RSI 70). This could be extended to incorporate backtesting. 3. **Workflow Definition:** Allow users to create `Workflow`s that consist of an ordered list of `Operation`s. Each operation in the workflow should be configured with its specific parameters (e.g., the period for a moving average, the price range for a filter). The workflow should be serializable and deserializable (e.g., to/from JSON) to allow for saving and loading workflows. 4. **Workflow Execution:** Implement an `ExecutionEngine` that takes a `Workflow` and a `Stock` as input and executes the workflow, passing the output of each operation to the next. The engine should handle errors gracefully (e.g., if an operation fails) and provide a log of the execution. The output of the workflow could be a modified Stock object, a boolean signal, or any other relevant data. 5. **Data Input:** The system should be able to ingest stock data from a simulated data feed (e.g., a simple in-memory generator or reading from CSV files). 6. **Caching**: The system should cache stock data and results of computations (e.g., MovingAverage, RSI) for a configurable period to improve performance. Implement an interface to support different cache implementations (e.g., in-memory, Redis). The cache should handle concurrent access and cache invalidation properly. ## Non-Functional Requirements 1. **Thread Safety:** The `ExecutionEngine` and data structures (especially the `Stock` class and the caching mechanism) must be thread-safe, allowing for concurrent execution of multiple workflows on different stocks. Consider scenarios where multiple threads are updating stock prices or executing the same workflow. 2. **Extensibility:** The system should be easily extensible to support new `Operation` types without modifying the core `ExecutionEngine`. Use design patterns that promote loose coupling and open/closed principle. 3. **Modularity:** The system should be divided into well-defined modules with clear responsibilities. Consider using interfaces and abstract classes to define the boundaries between modules. 4. **Testability:** The code should be designed to be easily testable, with unit tests for individual components and integration tests for the overall system. Think about dependency injection to allow for mocking dependencies during testing. 5. **Performance:** The `ExecutionEngine` should be optimized for performance. Consider caching intermediate results, using efficient data structures, and minimizing object creation. The cache invalidation should be efficient and avoid unnecessary locking. 6. **Maintainability**: The code should be well-documented and easy to understand. Use meaningful names for classes, methods, and variables. Follow coding conventions and best practices. ## Core Entities 1. **Stock:** Represents a stock with its price and volume data. 2. **Operation:** An interface representing a stock analysis operation. 3. **MovingAverage, RelativeStrengthIndex, PriceFilter, VolumeFilter, TradingSignal:** Concrete implementations of the `Operation` interface. 4. **Workflow:** Represents a sequence of operations to be performed on a stock. 5. **ExecutionEngine:** Executes a workflow on a given stock. 6. **DataFeed:** Provides a stream of stock data. 7. **Cache:** Provides a cache mechanism for stock data and operation results.

Build the Google Stock Wizard.

Requirements

Interview Simulation

Functional Requirements

💡 Interview Tip

Non-Functional Requirements

Core Entity Identification

Premium Content