# Senior Software Engineer Compilers and Programming Languages Take‑Home Assignment: Move View Function ## Overview This assignment evaluates a candidate’s ability to design and implement a feature in a compiler toolchain, specifically for the Move language as used in the IOTA ecosystem. The task mirrors real challenges in the VM & Language team routine development. Candidates should demonstrate: - Strong system‑level design skills - Understanding of IOTA compiler pipelines or bytecode analysis - Ability to produce clean, maintainable, production‑quality code - Proficiency in Rust (or an acceptable level if the candidate has rather more experience with C++) --- ## 1. Assignment Goal Implement a compiler feature (or compiler-adjacent analysis pass) that detects whether a Move function is a **view function**, defined as a function that performs no state‑modifying global storage operations and only reads from global state. More in detail, the [IIP-0005 (Move View Functions)](https://iotaledger.github.io/IIPs/iips/IIP-0005/iip-0005.html) defines view functions as Move functions that: - Return a value (i.e., have a non-void return type). - Never mutate on-chain state when invoked, meaning it does not perform any global storage writes or trigger other forms of state modification. - Could be used to query the blockchain state, i.e., given the above two properties a move view function can be invoked off-chain (via an RPC endpoint) without requiring a transaction, signature, or gas payment. :::warning Although IIP-0005 describes view functions primarily from the perspective of the SDK, runtime, or external tooling, this assignment focuses instead on a language/compiler-level implementation. Your goal is to statically determine which functions meet the IIP-0005 definition, based solely on what the compiler can observe in the Move module and its dependencies. ::: - Minimum requirement: - Analyze Move modules during the build process and identify which functions qualify as view functions according to the rules above. - Output the results, for example by printing a list of detected view functions during compilation. - Additional requirement - Your implementation must also make this information available to higher-level tooling. In practice, this means propagating the detection results upward so that any other caller of the IOTA Move module build routines (e.g., SDK tools or CLI commands) can retrieve and use the view-function metadata as part of their workflow. --- ## 2. Submission Format Candidates should: - Fork the [iota repo](https://github.com/iotaledger/iota) and create a dedicated private repo - Invite the following github users to the private repo with read only access: - @miker83z - @valeriyr - @lzpap - Submit the URL via email of a Pull Request once the work is done - The Pull Request must be done to the private repo and it should contain the following deliverables: - Short Design Document - Implementation - Instructions ### 2.1. **Short Design Document** Briefly describe the background information which was not provided in this take‑home assignment, but which was important during your analysis pre-design, e.g., the Move language on IOTA, the interested components in the repository, move "core" features helpful for this task. Then, related to the implementation, briefly describe the following points: - How “view-ness” is defined precisely in your implementation. - Where in the Move compilation/packaging/deployment pipeline you insert your implementation. - How you analyze Move bytecode or source code to detect state mutations. - How you report/surface your results (e.g., warnings, errors, an attribute, metadata). - Possible limitations or trade-offs. ### 2.2. **Implementation (Rust)** - Implement your solution as a patch against the fork of the `development` branch of the `iotaledger/iota` repo. This will be present in the PR to the private repo. - Implement some kind of testing (unit-tests or end-to-end tests) to show the working of your solution. - The implementation possibly needs not cover all aspects of the solution, but must reflect production‑grade thinking. ### 2.3. **Instructions** Provide a clear additional README file showing: - How to build and run the tests - Example Move modules - Expected output --- ## 3. Suggested Timeline - **Analisys and Design**: 2–5 hours - **Environment Setup and Implementation**: 0,5-1 hours + 1–2 hours - **Docs**: 0,5-1 hours Total expected time: ~4–9 hours. --- ## 4. Final Notes The assignment intentionally mirrors the complexity of systems-level engineering work in blockchain development. There is no single correct solution, but candidates should be able to justify decisions, show analytical thinking about the problem and show strong engineering discipline. Feel free to contact mirko.zichichi@iota.org if you have any questions.