FEATURE: Categorize questions by difficulty and random interview

Currently, we have around 30 questions. In order to implement difficulty category we would need a bit more, lets say 50+.

This issue represents mixture of my and @atomiks ideas.

We would like to implement some sort of real interview. When a user presses a button on a landing page he is redirected to a custom page where he is welcome with ~10 random questions. The user should be able to select dificulty junior, medior, senior for questions. We do not have Duolingo algorithms but @atomiks suggested that after each question user would press one of the 3 buttons:

• I know
• I partially know
• I don’t know

Each button would carry different weight and at the end of interview, user could see his score (summ of all weights).

In order to make this interview, we would need to categorize questions by difficulty too. Would such thing be hard to maintain? Do we need categories for random interview(junior, sentior etc.) or we should have one single category?

We could also display small tag on question’s card based on question difficulty on our main page.

What are your opinions on this one?

[fejes713]

This needs curation, and people arguing over how difficult a question is leads to chaos. That kind of makes it hard, so we would need to not allow pull requets to modify them and would instead have to allow people to vote for them over time with a reaction on a github issue(so authentication is taken care of) for the question in comment and lock comments to maintainers, but allow public to react(if possible)

This pretty much sums it all up. There is definitely going to be a lot of problems with deciding which questions goes where in terms of difficulty.

For now, we can just generate 10 random questions just for fun. Real interviews could come into play later down the line when we have over 100questions and someone to maintain and sort them properly.

[skatcat31]

Actually this could be done with a client side script. If they clear their cookies we would lose track of progress, but it would be entirely doable client side with those storage mediums(isn’t JSON great?)

The parts would be:

1. Question list script(generate and save the question list and their answers as an initial state)
2. Question display script(display the question and record their answer)
3. Results calculation script(calculate and show their result, offer a print or copy, make them the storage medium)

Any modification to the storage would mean an immediate loss of progress and having to start over, but since we aren’t going to be storing the results etc… etc… you can see where this train of thought is going.

However @Chalarangelo hit the nail on the head:

This needs curation, and people arguing over how difficult a question is leads to chaos. That kind of makes it hard, so we would need to not allow pull requets to modify them and would instead have to allow people to vote for them over time with a reaction on a github issue(so authentication is taken care of) for the question in comment and lock comments to maintainers, but allow public to react(if possible)

Otherwise this will require a server. It should be doable with the abilities that Github provides, but would mean manual labor time, or a server to aggregate and collate based on an algorithm