https://github.com/aershov24/pmsc_candidates_test
PMStack.Cafe Content Maintainer test repository
https://github.com/aershov24/pmsc_candidates_test
Last synced: 5 months ago
JSON representation
PMStack.Cafe Content Maintainer test repository
- Host: GitHub
- URL: https://github.com/aershov24/pmsc_candidates_test
- Owner: aershov24
- Created: 2022-10-16T22:50:33.000Z (about 3 years ago)
- Default Branch: main
- Last Pushed: 2023-01-03T17:39:02.000Z (almost 3 years ago)
- Last Synced: 2025-03-12T16:16:49.001Z (9 months ago)
- Size: 60.5 KB
- Stars: 1
- Watchers: 3
- Forks: 34
- Open Issues: 8
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Welcome to PMStack.Cafe Candidates Repo
Please read this document carefully before submitting your PMSC candidate challenge.
# What Do You Need to Do?
* Carefully read the `README.md`
* **Fork** this repository
* > Create the `Kanban_youremail.md` Markdown file in the forked repo and add **`3` questions and answers (QAS) relevant to _Kanban_ topic that you would ask on a real PM interview** if you need to hire a real **Scrum Master/Project Manager** for your own team. Add QAS formatted as Markdown into the `Kanban_youremail.md` file.
* All content must be formatted as valid Markdown (see examples below).
* Make sure you'll add:
* one **Junior** difficulty question (simple questions to test basic knowledge)
* one **Mid** difficulty question for **Middle** PM positions, and
* one **Senior** question for **Senior** PM positions
* Make sure that for all QAs you'll include:
* Question **Title**
* Question **Description** (optional)
* **Answer** (required)
* Link(s) to **Source**s (you don't need to write answer by yourself, just combine and research best sources that are available)
* QA **Difficulty** Level. Use that Difficulty enum: [`junior`, `mid`, `senior`]
* Look at the [`QAS_Examples.md`](https://github.com/aershov24/PMSC_Candidates_Test/blob/main/QAS_Examples.md) file in this repo for examples of QAS file formatting in Markdown. Use this file as a template for your submission. Please strictly follow these formatting conventions. This is **the key** to pass the challenge ;)
* Create a [pull request](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork) from your repo into the PMSC Candidates repo. Name the PR as `SCRUM | youremail`. PRs with different names will be rejected.
* Send us email or DM us on UpWork when you happy us to verify it
# How To Choose/Write Good Interview Questions?
When choosing a good interview question follow these rules:
* The QA should not be too **broad** or too **obvious/trivial**, like:
* 🚫 What is `Scrum`?
* 🚫 What does a Scrum Master do all day?
* The QA should be **opened** and invite the candidate for a conversation rather than strictly test his/her/their specific knowledge. Compare:
* 🚫 What is `Sprint` in Scrum?
* ✅ Provide some ways to fit _bug fixing_ into a Scrum process. How would you fit it on an `Kanban Board`?
* ✅ What is the difference between _Sprint_ and _Iteration_ in Scrum and _length_ of each Sprint?
* Keep the answers **short**, **succinct** and **informative**. If you feel your answer is growing in size and covers different topics the split it!
* Avoid highly practical questions like
* 🚫 How best to do Agile Development in MS Project? - we won't accept that type of questions
* Don't submit behavioral questions like:
* 🚫 Describe your strengths and weakness, and so on
* Use that that types of questions:
* ✅ `When to use X vs Y?`
* ✅ `Why would you use X?`
* ✅ `Compare X vs Y for solving Z`
* ✅ `What types of X do you know?`
* ✅ `Are there any problems when using X for solving Z?`
* ✅ `Name some advantages of using X vs Y for solving Z?`
* ✅ `Explain X to 5 yo/your grandparents`
* ✅ `What is example of Y in real life?`
* ✅ `Provide an intuitive explanation of X`
* The best **rule of thumb** to follow is
* ✅ ask yourself would you use this question on a real Agile Coach/Acrum Master/Project Manager interview? If answer is "Yes" then go for it!
# Where To Find/Source Good Interview Questions?
Remember, **you don't need to reinvent an interview question and the answer by yourself**. Your task is to research the best sources that are available on the Internet (blog posts, books, videos, tutorials), _combine_, _convert_ and (sometimes) _reformat_ that existing knowledge into the answer.
There is just a fraction of quality resources you can do you research on:
* Books on Agile, Scrum, Kanban, PM, PMBOK
* scrumguides.org
* stackoverflow.com - 💡 **Hint**: sort questions by Score (or Votes) in search
* pm.stackexchange.com
* github repositories (with many stars, not forks)
* gitbooks.io
* atlassian.com
* monday.com
* pmi.org
* age-of-product.com
* pmhut.com
* thetaoofpm.blogspot.com
* etc...
💡 **Hint**: Don't blindly copy all answers from one source for the same topic. Try to find at least 2-3 source of the information and choose the best explanation **you like most**.
💡**Hint**: Search Github for pm interview questions repos that other people did. Usually they already formatted as Markdown and can get you great amount of QAS for the topic
💡**Hint**: When research on some topic look at the `Table of Content` in your favorite project management book to get a sense on what subtopics you can cover. Most of the Coursera and Udemy courses will work too!
# Resources to AVOID
⚠️ **Warning**: Don't use/copy information from the websites with bad grammar and poor QAs quality. We won't accept QAs that will be copied from poor quality resources and will reject your submission. You can recognize these sites by deficient crappy design, low quality images, tons of ads, lack of code formatting and code samples and _no attribution to the sources of the answer_ like:
* onlineinterviewquestions.com
* geekforgeeks.com
* career.guru99.com
* educba.com
* edureka.co
* a4academics.com
* etc ...
# How To Format Interview Questions + QAS Examples
All interview questions must be formatted using those rules:
* use ONLY **Markdown** ([Github flavour](https://guides.github.com/features/mastering-markdown/))
* **Do** include images (include them as Markdown links) into your answers if they help to explain concepts you cover
* **Do** use and reformat original source of answer using **lists**, _italic_ and **bold** for better readability
* **Do** include formatting in the QA title
* **Do** format the code (see samples)
See some examples of QA formatting below. Note how to format **list**, **code**, **file names**, **terms**, **links**, QA **difficulties**, **images** and so on. To see more QA formatting examples go to [www.fullstack.cafe](https://www.fullstack.cafe) and explore this QAs library.
---
## Q1: What is the difference between _DMAIC_ and _DMADV_ in Six Sigma?
**Difficulty:** `Junior`
**Source:**
https://www.vinsys.com/blog/strategic-difference-between-dmaic-and-dmadv/#:~:text=With%20regard%20to%20measurement%2C%20DMAIC,model%20to%20meet%20customer%20requirements
**Answer:**
* **DMAIC** stands for: Define, Measure, Analyze, Improve, Control
* **DMADV** stands for: Define, Measure, Analyze, Design, Verify
Despite the first three shared letters of their names, there are some notable differences:
* **DMAIC** typically defines a business process and how it applies; **DMADV** defines customer needs as they relate to a service or product.
* **DMAIC** measures the current performance of a process, while **DMADV** measures customer specifications and needs.
* **DMAIC** focuses on making improvements to a business process to reduce or eliminate defects. **DMADV** develops an appropriate business model to meet customer requirements.
---
## Q2: How do you deal with _bugs_ or mistakes in Kanban? Would you move items back on a board?
**Difficulty**: `Mid`
**Source:**
https://pm.stackexchange.com/questions/3935/kanban-moving-items-back-or-how-do-you-manage-mistakes
**Details**:
Given that you have a feature tracking through your Kanban board, the dev marks it done, it's pulled into QA, and the dev pulls in new work. QA fails the item.
Now what? Would you move the item back to the Dev stage? What will you do if you can't move it back into the dev stream as it's full?
**Answer:**
My first advice would be to treat your QA stage as the one **covering both**: _testing_ and _bug fixing_ which basically renders the problem of moving index cards anywhere irrelevant. Developers work in the QA stage (same as testers) when they are fixing production defects.
I won't personally **move cards back** as it just adds a lot of hassle. You can have policies that you can violate limits in such situation but chaos introduced isn't worth the value.
Other options to consider might be:
* You may **"park" features** which didn't pass testing. You may have dedicated subcolumn where you put such features so everyone knows that they require bug-fixing.
* You may just **visualize status of testing**, e.g. testing started, testing passed, testing failed, with additional visual signal and keep the index cards in QA column.
* You may **deal with bugs using additional information radiator**, usually not a full-blown Kanban board. Then, again, you keep the index cards in QA stage but you deal with bugs independently.
---
## Q3: What is the role of the _1.5 Sigma Shift_?
**Difficulty**: `Senior`
**Source:**
https://www.qualitydigest.com/inside/six-sigma-column/15-sigma-shift-explained-040406.html
**Answer:**
Experience has shown that processes usually do not perform as well in the _long term_ as they do in the short term. As a result, the number of sigmas that will fit between the process mean and the nearest specification limit (SL) may well drop over time, compared to an initial short-term study. To account for this real-life increase in _process variation_ over time, an _empirically_ based 1.5 sigma shift is introduced into the calculation.
According to this idea, a process that fits 6 sigma between the process mean and the nearest specification limit in a short-term study will in the long term fit only 4.5 sigma – either because the process mean will move over time, or because the long-term standard deviation of the process will be greater than that observed in the short term, or both.
**NOTE**: With the introduction of the 1.5 Sigma Shift the "6 sigma" process will have long-term defect rates corresponding to 4.5 sigma performance rather than actual 6 sigma performance.
In practice, the 1.5 sigma shift results in the generally accepted six sigma value of **3.4 defects per million** opportunities:
_Ignoring_ the 1.5 sigma shift results in a six sigma value of **2 defects per billion** opportunities:
---
# How We Asses Your Work
Look at this list of criteria that we will keep in mind when assessing your submission:
* _Variety_ and _Quality of Sources_ you have used. We hard stop and reject your candidacy if you copy/source QAs from one source or sources mentioned to AVOID
* _Markdown Formatting_ Quality - don't blindly copy answer, **RE**format it to increase _readability_, for example:
* Use paragraphs and new lines to visually separate different parts of the answer
* Use **bold** for terms and acronyms
* Use **lists** to visually separate different concepts especially if they presented in one long sentence in the source
* Use _italic_ to stress attention on critical/important _idea_ or _concepts_ or _hints_ for a reader
* Use _italic_ in QA Title for terms and acronyms
* Use `code` for numbers: `123`, percentages: `68%`, `file_names.md` and code `