Build a mobile app that takes a picture of a resume and recommends jobs based on that.

This is definitely a unique one but a very precise design question at that. Let me first understand scope a bit.

1) I can assume we are focusing on US geography. Is that ok? (yes)

2) We can assume this be for any OS. (yes)

3) We can assume this is for any field. (yes)

4) Are we focused on specific levels of professionals? (no)

5) Should we be able to just find a job or also apply thorugh the app? (your pick). Ok, I thinkwe shuld keep the option open to be able to apply but let's see what makes sense depending on whom we might be building this for.

I am thikning of scoping by thnking about Who, What, When, Where, Why and How...let's see...

6) Is there a reason for why we are trying to build this for Glassdoor? Meaning, do we have certain data points from complaints, logs, suggestions, etc. that we are going off of? (No no specific customer data).

7) ok but do we have any specific guidance from leadership as to the outcome? (no, we want to differentiate ourselves I guess).

Ok...considering Glassdoor is quite mature company, I think we want to provide better features for our customers to give them a reason to use us more. So basically retention is our interest? (sure).

I think it's important to think about who might wnat to use this since as per my experience, solutions depend on user's wants. Then we can talk about few options and see what might be an MVP. Sound like fine approach?

Interviewer: Sure.

Me: I think there are different type of job seekers...1)Interns/students 2)NEw professionals 3)Seasoned professionals and maybe some others who could belong to either of the other groups 4)Returning to workforce 5)Field changing professionals. I think the fact that we want to build an app to help recommend a job leads me to say we shouldn't focus on #3 since seasoned professionals usually have a network to depend on and even if they don't they don't need a tool to help recommend what job to apply for. They typically know what they want and format their resume catering to that type of job. Also, #4 have had time to work on resume and think about waht they want so don't think they are going to use this tool and #5 they have strategically planned mostly so they prob already know what to look for. Yes there are cases where you get laid off and aren't skilled enough for what you were doing so now are trying to change to a simpler field but those are few and far between. Looking at masses, I think we should focus on #2. #1 gets help from career services and such.

Interviewer: I agree.

Me: Ok ...let me think how to make the tool interesting.

1) I wonder or may wonder if f my resume is interesting enough.

2) I wonder or may wonder if resume is missing out on better opportunities.

3) may wonder how many people have been shown the same job.

I was thikning abiout me using this tool and what I might feel. I think all of these are something my user would also wonder so I am going to try and address all of these.

1) I imagine the tool would have some sort of settings whereby I can choose multiple different type of jobs that I want. So filters could be: Industry type, Company size, Company revenue, City, Profession type, demographics of the employees, Frotune 100 /500 ranking, Perks, etc. I think these are plenty to start with and I also think our inexperienced or rather new professional prob isn't that picky. So I doubt this would be an MVP but let's roll with this for a min. My user would choose all or some of these options, then scan the resume and the jobs will be showcased based on criterions selected. Eval: Value add to user: 3-4, Compelxity of implementation: 3 (some logic involved to obtain all this information via APIs so maybe difrerent APIs from different sources and then anotherr API to stitch all that info together). I do thikn this one addresses my pain point #2 since I know resume is giving me choices baed on my criterions.

2)Maybe a swipe feature whereby I swipe left and ML engine learns from metadata what I don't like. But in the initial stage our swipe lefts are treated as training data (thiough before relasing we would have already used training data to tweak our model). I don't know enough about ML so maybe this might just need to be a re-inforcement logic. Anyhow, maybe my user has choice when to stop training the product. C=4 (computer vision, maybe some NLP and ML), V=5.

3) My user would likely like to know how many other resumes of similar type have seen this job and saved it or applied for it. So maybe we somehow categorize resumes in 3 buckets 1)relevant 2)somewaht relevant 3)extremely relevant or maybe that's a job category and resume category is 1)Newbie 2)Some experience 3)A professional. So then I can see oh great I am glad I was suggested this job but crap my resume is categorized as Some experience and there are 20 more "professionals" who have applied here. In fact, I can also see what total # of users in each category has seen this job (total is applied and not applied). This covers pain point #3.

4)I could do maybe be reocmmended to connect with other professionals with similar resumes. I don't see their resume but am showing others to network with. LinkedIn API integration here would make it work. This is imp since people of my job level when they get job their company is likely to have jobs for me (I think in the term that a Google is not going to be as interested in someone from Ulta beatuy but more interested in a FB guy). C=3 (API integrations are simple), V=5.

I realize I didn't address pain point #1 but I think these are good amount of solutions. Are you ok with that or do we want to try and address #1?

Intervewer: Be good if you want to.

Me: Well, time is limted and considering we have identified in my opinion what would matter to my user, I think we can skip it for now. In real life, I would have time and some user data (from interviews or research, etc.).

Interviewer: ok.

Me: I somewhat evaluated these solutions and I am leaning towards #2. I say this because applying is a painful process. #2 makes it easier for my user and I think that's important. #4 is also value add but my type of user is interested in putting out a fire at home vs trying to build a network. Having said that, I will go wth #2 but would want to measure and make sure we are approaching the right direction for hte product.

Aftter a month, I think that's enough time since most people are going to find a job in a QTR, I would measure # of sessions > 1 / per user. Ther is a chance that >1 is not necessarily success since after few sessions user may get tired if our solution isn't trained right. Bad data could corrupt training is a risk here for our solution. So I think it will also be important to measure sentiment.

Overall, to make a mobile app whereby my user can scan resume and jobs be recommended, I think it's important to focus on how to make the job finding process extremely simple but precise. That's what I attempted to solve here but the risk is high of bad data hence bad recommendation which would damage our branding.