Microsoft Engage 2021
The Microsoft India UR team is excited to announce the launch of the Engagement & Mentorship Program – Engage 2021 for engineering students. Through this initiative, students get a chance to be mentored by Microsoft and be a part of AMA Sessions, Webinars and Leader talks delivered by Microsoft employees.
Know moreThe Challenge
Build a functional prototype of a platform that gives students an array of digital academic and social tools to stay engaged with their studies, peers and broader university community during pandemic.
Here are few examples:
Scheduler
This feature that allows students to submit weekly preferences for attending class in-person or remotely. The tool then assigns available seats to students who want to physically attend class and provides the faculty with a roster of who has been cleared to attend.
Submission tool
Using this tool, the faculty can distribute assignments, and upon receiving submissions from the students - analyze, and grade assignments. The tool could have other features such as test case creation, autograders, and static code analyzer integration.
Online Forum
Creating a classroom community where meaningful conversations can happen isn't easy - it's an ongoing process that takes time. Using online discussion tools can be a great way to help students build these skills. The tool could have a "moderation" feature to hold discussions responsibily.
Unleash your creativity!
Don't restrict your imagination with just these examples. We would love to see your unique idea when you create a product that that encourages greater collaboration and engagement in times of a pandemic, while also keeping students and staff safe.
Video Demo
- Demonstrate how your product works.
- Video should not exceed 4 minutes in length.
- You would be required to upload the video to your favorite video-sharing platform and share the link with us.
Source Code
- Upload your Source code on GitHub and share the repo with us.
- Share your GitHub repo: Submissions are now open.
- Video demo & GitHub repo sharing are now available. Submissions are now open.
Schedule
This is how we roll!
Learn
Learn via our workshops & AMA sessions.
Concluded
Design
Apply your learnings. Design your product.
Concluded
Build
Build a functional prototype.
Concluded
Submit
Share your video demo & GitHub repository.
Submissions are now open.
(Ends on Nov 28th @ 11:59 PM)
Submit Prototype
Judging Criteria
A panel of Judges will grade each criteria with a score of 1 - 10. Take each criteria seriously.
Programs with similar feature set will be grouped under corresponding categories and may be measured for performance wherever applicable. The telmetry may include metrics such as:
- Execution Time
- Memory Consumption
- Program Size
- CPU Utilization
- Cycle Time
- Application Response Time
- Database Throughput
- Database Response Time
- HTTP Response Time
- HTTP Error Rate (%)
- AVG. Throughput (rpm)
- AVG. Memory (mb)
- AVG. Interaction Time (ms)
- Any other applicable metrics
Your source code may be evaluated for coding best practices. These are some of the parameters the panel of Judges may consider during code review:
-
Comments and Documentation: Perhaps one of the first things you learn as a developer is to comment your code. At first it may seem like a waste of time, following the mentality of ‘If they are a developer too – they can understand it’. While it is true some of the time, commenting your code and providing proper documentation will guide the other developers through the algorithm and logic that you implemented. But don’t get carried away and comment every line of code! Obvious code should be left as is.
-
Use consistent indentation: There is no right or wrong indentation that everyone should follow. The best style, is a consistent style. Once you start competing in large projects you’ll immediately understand the importance of consistent code styling.
-
Follow the DRY Principle: DRY stands for “Don’t Repeat Yourself. The same piece of code should not be repeated over and over again.
-
Code Grouping: More often than not, certain tasks require a few lines of code. It is a good idea to keep these tasks within separate blocks of code, with some spaces between them.
-
Avoid Deep Nesting: Too many levels of nesting can make code harder to read and follow.
-
Limit line length: Long lines are hard to read. It is a good practice to avoid writing horizontally long lines of code.
-
File and folder structure: You should avoid writing all of your code in one of 1-2 files. That won’t break your app but it would be a nightmare to read, debug and maintain your application later. Keeping a clean folder structure will make the code a lot more readable and maintainable.
-
Naming conventions: Use of proper naming conventions is a well known best practice. Is a very common issue where developers use variables like X1, Y1 and forget to replace them with meaningful ones, causing confusion and making the code less readable.
-
Keep the code simple: The code should always be simple. Complicated logic for achieving simple tasks is something you want to avoid as the logic one programmer implemented a requirement may not make perfect sense to another. So, always keep the code as simple as possible.
-
CI/CD & TDD: Adopt Continous Integration/Continous Delivery and a Test Driven Development approach.
CI/CD was created for agile development. It organizes development into functional user stories. These user stories are put into smaller groups of work, sprints. The idea of continuous integration is to find issues quickly, giving each developer feedback on their work and TDD evaluates that work quickly. With TDD, you build the test and then develop functionality until the code passes the test. Each time, when you make new addition to the code, its test can be added to the suite of tests that are run when you build the integrated work. This ensures that new additions don’t break the functioning work that came before them, and developers whose code does in fact “break the build” can be notified quickly.
You will receive points for every functional feature you create.
You will not receive any points for a feature that is just representational and does not work.
The Judges may use the following parameters as a guide to evaluate the UI of your prototype:
Accessible: Minimal accessibility requirements have been addressed.
Actionable: It should be clear how to achieve tasks/goals that your app/site/service is designed for; functionality should be clear (it is obvious what to press and what not to, etc.)
Consistent: Consistent: Consistency of information architecture (IA), visual and interaction design throughout the site/app/service. Your app/site/service should have a clear navigation, understandable labelling, well-defined iconography, orientation within the app/service/site is clear, links and CTAs (Call-To-Action) are obvious, well-labelled and consistently presented.
Cross-Platform: Works well across multiple platforms (unless specifically designed not to be multi-platform).
Flow: Does the user know where to start on the page? Is the path from start to finish clearly defined?
Visual: Your app/site/service should have an aesthetically pleasing visual design.
Your video demo should not exceed more than 4 minutes.
An excellent demonstration should be informative and follow a logical sequence and show how to do something. The Judges may use the following parameters to evaluate your video demonstration:
-
Oral Introduction: Did you Introduce yourself well? Were you able to capture Judge's attention?
-
Presentation: Did your Presentation informed the panel of Judges well of the topic being presented? Was your demo easy to follow and understand? Did the Judges find your information accurate and complete?
-
Creativity: Were you able to convey your topic creatively so Judges would remember your demonstration?
-
Performance: Did you show good inflection, proper pronunciation, used expression to demonstrate points, appeared conversational and natural? Was your voice loud and clear enough to hear?
-
Overall Impression: Judge's attention was captured and maintained, demonstration was informative and followed a logical sequence.
You might secure extra points if your product has that unexpected quality or functionality that's able to wow the Panel of Judges.
This could be related to UI/UX or that special feature set you may build.
LEARN
Workshops & Ask Me Anything Sessions
Topic | Date | Starts at (IST) | Ends at (IST) | Action |
---|---|---|---|---|
Engage Launch Kickoff | Nov 08, 2021 | 3:00 PM | 4:00 PM | Concluded |
AMA | Nov 09, 2021 | 3:00 PM | 4:00 PM | See Call Recording |
AMA | Nov 10, 2021 | 3:00 PM | 4:00 PM | See Call Recording |
Design Thinking & Agile Concepts | Nov 12, 2021 | 5:00 PM | 6:00 PM | Concluded |
What is PaaS, IaaS, SaaS? | Nov 16, 2021 | 3:00 PM | 4:00 PM | Watch Tutorial |
Azure Quickstart | Nov 16, 2021 | 3:00 PM | 4:00 PM | Watch Tutorial |
Build your first Web App with Azure | Nov 16, 2021 | 3:00 PM | 4:00 PM | Watch Tutorial |
How to migrate MySQL database to Azure | Nov 16, 2021 | 3:00 PM | 4:00 PM | Watch Tutorial |
Assignment 1 | Nov 17, 2021 | 3:00 PM | Nov 19 @ 11:59 PM | Closed |
AMA | Nov 18, 2021 | 3:00 PM | 4:00 PM | See Call Recording |
Campus to Corporate | Nov 22, 2021 | 3:00 PM | 4:00 PM | Concluded |
How to use GitOps with Microsoft Azure | Nov 23, 2021 | 3:00 PM | 4:00 PM | Watch Tutorial |
Why you should care about Containers | Nov 23, 2021 | 3:00 PM | 4:00 PM | Watch Tutorial |
How Kubernetes works | Nov 23, 2021 | 3:00 PM | 4:00 PM | Watch Tutorial |
How Kubernetes deployments works | Nov 23, 2021 | 3:00 PM | 4:00 PM | Watch Tutorial |
Nail that Interview | Nov 24, 2021 | 4:30 PM | 5:30 PM | Concluded |
Assignment 2 | Nov 25, 2021 | 12:00 PM | Nov 26 @ 11:59 PM | Closed |
AMA | Nov 25, 2021 | 3:00 PM | 4:00 PM | See Call Recording |
Why Microsoft? | Nov 26, 2021 | 3:00 PM | 3:45 PM | Concluded |
Final Submission | Today | Submissions are open | Nov 28 @ 11:59 PM | Submit Prototype |
TBA - To Be Announced