Skip to content

Latest commit

 

History

History
34 lines (23 loc) · 3.46 KB

Extra Reading.md

File metadata and controls

34 lines (23 loc) · 3.46 KB

Why this format

As a community, there are many gaps between academic coding and professional coding. There aren't enough tools or sources of information for developers that help them be successful at their first jobs, or even help them succeed in the hiring cycle and the job application process, the interview process, etc.

Here's the first big difference between academic coding and professional coding:

  • In academic coding, you're writing code that will last you for a week, a month, or maybe at max a semester.
  • In professional coding, the code you write could be with you for decades. You will also inherit other people's code, possibly written decades ago. And your code will be inherited by others after you. And your coworkers and you will be modifying each other's code over the course of your employments there.

The exercise we will be presenting you will be intentionally simple so that you can focus on writing clean code in a fair amount of time, rather than rushing to make something that looks good on the screen but is a ball of wax in the repo. So, let's not make spaghetti -- we want to make lasagna, nice and layered code that's easy to reason about.

So, in a professional setting, you write code for other people, not just for the machine, not just for yourself, and not just for the grade. This is something that gets glossed over in academic settings. Collaboration is very rarely taught rigorously and in the right way in schools.

In CareerHack, we provide developers with information they can use in their own careers. Part of this involves spreading knowledge of best practices and design patterns through code review in Part 2. Another part of it is Q&A and discussions in the chatroom.

This is a solo hackathon for the most part. In the first half, you will be writing code so that others can read it. In the second half, you will be performing code reviews as a group. You will be receiving feedback from others (and possibly from me too) about the code you just wrote, and you will have the opportunity to provide feedback to others as well.

Why a standardized data format for résumés is important

Having standardized data formats lets people collaborate on building a better ecosystem of tools. Here are a few examples where this has already happened:

  1. The *.mp3 format allows music creators, streaming companies, software companies, open source tools, and listeners focus on making & sharing great music.
  2. The *.csv format lets all kinds of software systems talk to each other using imports/exports, while letting human beings retain the ability to clean and format large datasets using tools that understand *.csv files.
  3. Image formats like *.png, *.jpg, *.gif
  4. The http protocol

A standardized résumé format, if one arises, enables many cool things:

  • Candidates could automatically apply for 1000's of jobs in bulk.
  • Candidates could simple "install" pre-made themes on top of their resume data.
  • Candidates would experience less bias in the screening process, because résumé design and writing skills become less important for success.
  • Candidates would become much more discoverable, because the structured data allows more efficient sorting/filtering
  • Data scientists could run deeper analyses of the job market on well-structured data.
  • The community could build advanced tools on top of the résumé format that could enable functionality that we haven't yet thought of.

And there are probably many, many more advantages that aren't listed here.