B.R.E.A.K

GUI
Terminal GUI
Dataset
A summary of our database construction

Inspiration

We were inspired by speakers, seminars and personal experience showing us the problems implicit bias can cause when hiring. We found ourselves dissatisfied by the existing measures in place, and so chose to develop our own attempt at alleviating this bias.

What it does

We are striving to develop a project which can at least mostly circumvent these implicit biases through providing a blank slate for applicants. By removing all personal information irrelevant to qualification and skills, potential hires give an initial impression not through name, but through expertise.

 The program works first starting by requesting input from the applicant. Name, email, city and address are all requested, as well as a PDF copy of their resume. 
 The resume is then copied, the copy parsed for the aforementioned data. Said data is then redacted from the document, creating a version containing only qualifications. Both file copies are then renamed with a unique applicant number and placed in a folder for future reference.
 Once the files have been processed, the potential client/hirer can choose to either sort by education, previous employment/experience, or individually check each applicant one at a time. The redacted or "blank" files are only available until an interview has been set up by pressing the "accept applicant" button on the GUI (absolute restriction feature to be implemented in future update), at which point the original file is made available. 
 If an applicant is accepted, an email to the HR department is automatically sent, containing the relevant email.
 If an applicant is declined, the file can either be set aside or deleted.

How we built it

 First, a Trello was made to outline and prioritize the features we wanted on our finished product. Add-ons were ordered in a manner by which they would always be usable no matter how far along we were when time was up. 
 During the composition of our preliminary design, we were faced with a myriad of ethical questions that would dictate the course of our project. Once we had an idea of what we wanted, we set out to determine what would be redacted vs what would need to stay, as well as when the redacted information would be made available. The balance that was decided upon was to redact names, email, address, and images (although images were not completed in this iteration). Redacted information would be made available after an interview was scheduled as it was the maximum amount of time implicit bias could be avoided without compromising the hiring process. 
 First, a minimum viable product was created. This consisted of a program which would request the PDF, applicant name, address and email, then parse for the info and redact it, yielding two copies.
 Next, a GUI was created (tkinter module) to allow for the automated acceptance and delivery of information, as well as creating the proper interface which would hopefully ensure the success of our program in providing a blank slate to applicants. 
 After the GUI, the email program was made to send emails to HR and applicants post-acceptance of resumes. This was a large step in the ergonomics of our project.
 Finally, the database was made in SQL. The database was capable of holding a huge amount of sorted information which could be rapidly accessed and searched using different parameters. The search features immediately created were graduated universities and previous experience.

Challenges we ran into

 Feature creep proved to be an issue early on in the project, misdirecting us as we attempted to layer our efforts as mentioned in the previous section. 
  Additionally, lag in the email system (likely due to storm conditions) caused a perceived bug; one which was literally impossible to solve, but rather had to be discovered through thorough troubleshooting.
 None of us had ever used SQL before, so learning it proved to be quite a challenge, albeit a fun one.
 In that same vein, Steven was entirely unfamiliar with Python and so spent a good portion of the morning learning and applying the new language.
 Connecting the database and GUI was difficult as the data was being collected incorrectly. This warranted substantial troubleshooting and corrections which were slowly yet surely worked out.

Accomplishments that we're proud of

 We are proud of our database, email system, fast learning of SQL, and our confrontation of ethical dilemmas.
 Our database, written is SQL, was composed of a table containing UIDs for each individual applicant and their relevant info. This allowed a hirer to categorically search for and view applicant fitting a desired qualification or educational background with ease. The formatting of the database (linking info against the applicant #) also allows for additional search parameters to be designed with extreme ease.
 The email system is simple in nature, however the integration of external functions and features paired with sending customized yet templated information was a tricky puzzle we were proud so solve in short order. The email system we designed is also capable of sending to additional specified recipients if the user so chooses.
 SQL, while simply a new language, is a key to an entirely new frontier to each of us. While it is not a feat to learn in itself, we eagerly look to the future at the many new possibilities it has opened for us.
 We are proud of our ability to work through the ethical dilemmas presented to us. We were treading a fine line in executing our ideals, however we believe we did so in an excellent manner.

What we learned

 Some members had to learn Python on the fly, and we all learned numerous skills such as automated emailing, PDF parsing, function optimization, SQLite, database management,  project prioritization, file management, local hosting (not applied in end product), and tkinter.
 The greatest undertakings to learn and apply were SQL and database management due to the sheer complexity and versatility presented in their use.