It’s that time of the year where students are polishing up their resume/CVs to send out to companies for an internship or full-time job. I am always so surprised how lax students can be with them. Your resume is most likely going to be your first impression with the company. It’s worth investing some time into a well made one.

There’s no one right way, but I think there is some decent direction to be found in this post. It could be your zillionth time re-doing yours or maybe you’re making one for the first time. Either way, I hope this helps you along the way. So, take this for what it’s worth and let’s get started!

Structure

Education, experience, side projects, and then everything else.

Some people will argue to put experience first, but I’ve had several top companies (like Google and Microsoft) tell me to put my education first while still being a student. So, I’m going to stick with that for now. Once you finish school and begin working then I believe at that point experience should be listed before education.

Suggested format:

FF: I include my dates on the first line to the far right (either company name or project name line).

Intro

Your Name

e: my@email.com t: (555) 555 5555

links to all the things: linkedin.com/in/you, myweb.site, github.com/you, etc.

Please make sure these are working hyperlinks! Nobody wants to copy & paste. Later on, when we look at projects, if those are online then provide links to those as well!

Education

School Name, State/Province

Program — GPA (optional)

- Any relevant details like awards, initiatives, etc.

Work Experience

Company Name, City, State/Province

Position — Team

- Responsibilities

Projects

Project Name, list of major technologies used/implemented (by you)

- Responsibilities

- Major take-aways

The reason I like this format is because it makes it easy for someone to skim. I will include some templates at the end.

Other great ways I’ve seen these parts formatted are:

Program Name | School Name

Dates From — To

- Amazing awards and things

Dates — Position — Company Name

- Responsibilities

Dates — Project Name— technologies used

- Responsibilities

This brings us to crafting the content for our resume.

Content

I think students forget that it’s not just about showing you were once employed or stating that you worked on a project. It’s about highlighting what you specifically contributed to and how.

When listing your responsibilities/accomplishments one way is to format it in the following way: accomplished [X] by doing [Y]. Start with an active verb followed by a description. If you can include a quantifiable measure that’s a bonus!

Example 1:

• Tracked and handled the computer science association expenses and budget
• Tracked and handled the computer science association yearly budget of $8,000 for the 2017–2018 academic year

Quantifying makes it more powerful!

Example 2:

• Selected Microsoft Student Partner for Concordia University
• Selected as one of 50 candidates for an 8-month program to train students to develop on Microsoft technologies and deliver high-quality educational workshops to software developers.

It doesn’t have to be fancy, but the more specific you are, the better!

Let’s look at another example, “Increased the crash-free rate of applications to 98.9%”. One better could have been to include a comparison like “Increased the crash-free rate of applications from 80.2% to 98.9%”. In this form, you can easily describe how you achieved a particular goal.

Most common mistake

Including every little detail of your life.

“Be brief, be you.”

You do not need to jot down every little thing you did, that’s what the interview is for. Your resume is to get you the interview. It is not to tell your life story. It is not to get them to say yes right away. It’s a tool to get you an interview. You’ll have plenty of time to share more about the work you did with the company as you go through the interview process.

Keep it on point — “A concise resume demonstrates an ability to prioritize”. You need to take the time to properly go through and cut back on the irrelevant details. If you shove everything into your resume the recruiter/interviewer can be overwhelmed. They may end up skimming your resume and focusing on the less important parts meanwhile missing the important things you did. Do not fall victim to this mistake.

How do I know what to include?

A word to the wise, not every job or project in the past is relevant. Your camp counselor position from three years ago may not be relevant if in the mean time you’ve interned at companies and been a part of competitions or academic societies. Again, become a master of prioritizing. If you know what position you are applying for then tailor your resume to include projects and jobs to the job you are applying for. If it’s a front-end position then add that project where you designed and implemented the new societies website or if it’s a testing position then add that testing framework you built, etc.

When thinking about what content to include, put yourself in the shoes of the recruiter or hiring manager. Try to think about what stands out most about you. Include projects where you learned the most, ones you struggled through, ones you had disagreements with team members. They want to see how you handled challenging work experiences. With challenging projects, you can discuss dealing with conflict and disagreements. Another great piece to share is a project that you’re most proud of. That way when you have to talk about it the interviewer can hear and see your passion as you speak. All this together, you have valuable experiences to share.

Focus on what you can control

Let’s start with one of the most important facts. The golden rule: If it’s on your resume, it’s fair game. You included a C++ project you worked on in first year. However, you are having trouble remembering C++ concepts (note: interviewers won’t be too concerned with you remembering 100% the syntax of the language, I’m taking about concepts like pointers, multiple class inheritance, etc.). Either brush up on concepts that are specific to language or take it off your resume. There’s nothing worse than getting to the interview and not being able to run through a coding question, because you ‘forgot how things worked for that language’ meanwhile you included it on your resume.

How you deliver the content is in your full control. Use power words. Below you will find some words you can use to help make your content more descriptive:

• trained
• built
• introduced
• strengthened
• projected
• oversaw
• conceptualized
• implemented
• improved
• adapted
• solved
• initiated
• planned
• managed
• increased

Fonts

Choosing a good font is important. I’ve heard Serif fonts are better for printed copies and Sans-Serif is better for digital copies. I tend to use Sans-Serif type fonts like Arial, Calibri, Verdana, Times New Roman, or Trebuchet MS. You can read up on the debate and choose for yourself. I just tend to prefer these fonts… I don’t have a solid stance on this one. Just make sure it is clean and legible.

Be consistent

This is a less important point, more of an OCD for me personally. If you have 4 bullet points for a job and then one with 3 bullet points and another with 2 bullets points… I find it makes the resume look uneven. I have my personal belief that this leads to an inconsistency that can cause the recruiter to focus more on certain ones and missing others that would have actually been better for them to notice. I’d suggest keeping everything ‘even’ and if you can make everything with the same amount of bullet points. I’d recommend no more than 2-3 bullets for each position. Anything more I feel you’re not prioritizing your work. Anything less and maybe it’s not important. Nonetheless, each bullet point should include an action, tool(s) and technologies used, and if possible the impact/outcome.

Sell yourself!

Cool. Okay, but how do I sell myself?

If you don’t think what you did was important, then why should a potential employer think so? This goes back to crafting your content and focusing on what you can control. I’m not talking about lying, but show pride in the work you did.

Take for example, I came across a resume that said in the side projects/extra curricular section “I love hackathons”. But there was no mention of hackathon projects. Even if it the project was incomplete list it and say what you learned from it. In the interview, you will be able to talk about why it failed and what you would do differently. Take failure as an opportunity to show lessons learned and show your growth as a junior.

What about the languages I speak?

Yeah, go for it. Put those bad boys on there. If you’re fluent in it. If you can’t hold a conversation then leave it off.

But Kim, what about my GPA

Have a 3.2? 3.4? 4.0? Good for you. Include it. Else, leave it off.

Quick Tips

• One page.
• Easy to read font.
• Minimum 11-point font, max 14-point for descriptions (headings are at your discretion.
• Bullet points are not bad.
• Reverse chronological order for each section.
• Short and precise sentences are your friend.
• Do NOT lie. Under any circumstances.
• Be clear — descriptive enough for technical person, but general enough for someone less technical.
• Grammar, grammar, grammar. Make sure to have someone with good grammar look over your resume.
• Use a professional e-mail address. If you do not have one, create one! Avoid numbers and odd characters in your e-mail. It’s just easier when giving it out.
• I’ve been told not to use passive verbs. But honestly, I think the most important thing is to just be consistent. Don’t use a mix of passive and present verbs. Choose one tense and stick with it!

In conjunction with your resume

Social Media

Clean up your social media — or make private. We live in a digital world. Recruiters and interviewers will do a quick search on you. If you leave your content open be mindful of the following on your social media:

• foul language
• pictures of you drinking/partying inappropriately (now a picture of you with a beer is probably fine, but you being lifted over a keg, maybe not).
• gambling
• immodestly dressed

At the end of the day, you can disagree with me on these items and that is fine. At the end of the day you are old enough to make a judgement call of what is appropriate and what is not. Just be mindful of these things.

LinkedIn

Whether you like it or not, LinkedIn is a very important outlet to leverage at this stage of your career. I know many students that got interviews and jobs through a recruiter finding them on LinkedIn. Here are some points to improve your profile:

• Customize your URL.
• Use keywords in your content — for example you can check results for location and frequency of words.
• Use a professional photo only — not something you’d post on Facebook.
• Utilize the 110 characters wisely for your headline.
• Include visuals for your projects and such — gifs of your project running, YouTube videos, presentation slides, etc.
• Connect with people. But don’t over do it. If you are adding someone you do not know I personally appreciate when they include a short message of why they want to connect with me. I believe it’s proper etiquette instead of just hitting add to a bunch of people. Your call. You do you.
• Provide contact information.
• Try to get previous employers or organizations you volunteered for to give you a recommendation.
• Join relevant groups.

A last note about LinkedIn. The way I use it is I include almost everything, whereas my resume is the condensed version with the items I feel are the most important. But I don’t think there’s a right or wrong way for this one.

Big no-no’s

All the things listed below are items I endured while going over resumes…

Typos are still the most common mistake.

If you are sending a digital copy please do us all a favor and save it as PDF! Please do not send it as a Word document (unless explicitly asked for of course).

Make sure THINGS ARE ALIGNED. Line up your dates. I don’t care how hard it is. Otherwise, it makes you look sloppy and careless. That’s not the impression you want to give.

Do NOT make an image out of your CV… it becomes pixel-ated and looks absolutely horrendous. Just don’t do it.

If you say you are currently enrolled in a secondary education program please list the program of choice or indicate your situation. I’ve seen people just put the school with no indication of program or faculty. Knowing these details helps the company access what to ask you during your interview.

Same goes for when you are listing experience — don’t just list the company name or don’t just list the position. Include the company name and the position/title.

Please make sure there is no blank pages at the end. While you’re at it, make sure if you have more than one page that the last page is not half empty. Cut something out. You shouldn’t have half a page or less. Most probably they won’t take a second look at the second page (even if it’s full). Again, learn to prioritize.

Do not highlight anything. For any reason. What-so-ever.

Do NOT include a transcript unless asked and if you are asked usually you include it separate.

Do NOT include references. Same reason listed above.

Do not leave anything blank. For example, if you are currently attending a school do not leave the graduation date blank and do NOT put question marks. Put an estimate date.

Do not put it in landscape mode. The only case I could see this being okay is if you are going for a graphic design position and you are being creative and can make it work. Otherwise, no.

Do not use progress bars to demonstrate your skill level. That thing would never be full. It’s confusing and no one agrees on it.

Do not include a photo of yourself. There is absolutely no reason an employer would need to know what you look like.

Avoid tables. But if you must, make the borders invisible. It’s not visually appealing and is unnecessary. Unless you are good with design and can make it look good…

Some other quick things to leave off the resume: age, birth date, ethnicity, nationality, SSN #, high school education (if you are in University), home address, immigration Status, relationship status, gender identification, sexual orientation.

Coda

Remember, your resume will guide your interviews. I’ve included two templates that I hope can help beginners get started. These aren’t the best but I wanted to include a visual to show you the important points to capture.

• Template One Link
• Template Two Link

Why don’t you have a skills section?

I believe that sections like experience and projects should highlight the skills you gained and how you’ve applied them. If these are well documented in each part than a skills section will be redundant. You only have so much space to work with so make every little word count.

Final thoughts

Most important is knowing you’re more than a piece of paper. So, make sure to invest in improving yourself for your benefit. Not just because it looks good on a paper. You can usually sniff out who’s not genuine. And if not, it eventually comes to surface at some point. And then later it can bite you in the butt.

So, you might be wondering what else can you do to work towards getting your dream internship… you’ll have to come back at a later time! I’ll be sharing advice on what you can do beyond the resume.

I’d love to hear and see how you are all crafting your resumes so please share with me tips and tricks you found useful :)

I still remember the first hackathon I went to. I was too shy to attend as a hacker, so I had decided to volunteer. It was WearHacks Montreal back in September of 2014. I was fascinated by the people I found myself surrounded by. What kind of people would spend their entire weekend working on a project? They started from scratch, They worked with complete strangers, they barely slept, and all just because they loved what they were doing.

Before I knew it I was going to a different city every weekend. One weekend I would be in Philadelphia attending PennApps, to MHacks in Michigan (a 14 hour bus ride by the way), to HackHarvard, all the way to Brown University’s HackBrown in Rhode Island. Taking a plane became second nature. It was surreal. In the Fall of 2015, from September to December, I think there was a total of 2 weekends where I was home in Montreal. To top it all off, in January 2016 my hacker collective hosted our first ever ConUHacks at Concordia University.

When I look back on that year, the weekends all just kind of meshed together and it’s all kind of fuzzy. I remember being very tired all the time, but high on the fumes of RedBull, pizza, and smelly feet. I was enchanted by opportunity and possibility. After all that I had accomplished that year, I still felt like I had no idea what I wanted to do. I was constantly bombarded with questions like “What do you plan to do after University?” and “What area of software do you like?”. I didn’t know. But what I did know was that I had found something. I could feel it and I wasn’t ready to let it go.

Introduction

In June 2016, I found myself at HackCon IV, the official hackathon organizers’ conference, in Denver, Colorado. I was surrounded by the students who make hackathons across North America possible. I couldn’t believe I wound up there, standing a top a mountain in the Rockies.

That weekend was just like all the hackathons weekends I had trudged through, fuzzy but filled with excitement, opportunity, and possibility. The one thing I do remember vividly was a talk by Brandon Keepers, who at the time was the lead of Open Source at GitHub. He gave a talk entitled Contributing to your career. He spoke about open source and how it is created by everyday people. He went on to say that there is nothing stopping any of us from being where we want to be. With the right tools and the right support, you can get there. And I think it was in that moment I learned a bit about myself, about what I believed in, and what I wanted to do. I was crazy about this community and I was eager to take my next steps.

Following Keepers talk was the announcement for the launch of their Campus Experts program. I had this instant rush of passion, desire, and just pure excitement for this opportunity. I immediately grabbed for my phone and jumped online to fill out the application. After a bunch of the standard questions, ensuring I was in fact a living breathing non-robot thing, there was the last question. The golden question, “Why do you want to become a GitHub Campus Expert?”. You only had 500 characters to explain. How could I cramp everything that was going on in my head into 500 characters?

So I stayed up that night laying in bed listening to the half functioning fan desperately trying to make another full rotation. While starring out the window at the mountains with the stars that laid a top like sprinkles, I thought to myself, “How I could put a bit of myself into that message?” I pondered on the thought of how I could show them who I was and how incredibly head over heels I had become for this community.

The weekend past and I still wasn’t sure how I was going to finish the application. The more I read about the program the more I had this growing urge to just start doing all the things I really wanted to do, but always made excuses. I wanted to start writing blog posts, I wanted to give workshops, I wanted to give talks... I didn’t want to just attend events anymore, but I wanted be at the front line. I finally decided to write up a typing effect in JavaScript that would write out my message to GitHub. It was the best way I knew how to make the message more personal and reflect myself.

I hit submit and waited.

The program

Before I knew it, I was headed into an eight week program along with twenty nine students from around the world. Despite falling in the time frame of madness that is midterms, we were all more than happy to be on board.

Throughout the weeks, we received an incredible amount of support from the GitHub organization. We got assistance in how to organize tech events like tech talks, hacks nights, and hackathons. We learned how to put together technical content. We were given opportunities to develop engaging talks/tutorials along with an opportunity to present and rehearse them. We were given resources and tools needed to build and grow our community.

Wait, what is the Campus Experts program?

The Campus Experts program began with the notion of let’s find the people on campus who are leading their tech communities and help them get better at it. The program focused on building our communities. It offers the opportunity to gain experience in organizing events, in public speaking, and in technical writing.

What it boils down to is the following: We will help you bring together your community to network, learn, share, and celebrate!!

The process

We began by examining our communities’ demographic, our current resources, and our current communication mediums. Starting small wasn’t frowned upon and simplicity was favorable. Through analyzing and defining our community we got to set a clear goal(s) and designate the steps we would take to accomplish them. And more importantly we were reassured to not be discouraged if we didn’t meet our goal on time. There was no one way and no one right way. It was an adaptive process and we got craft and mold our community into what worked best for us.

The most significant aspect was there was no one cookie cutter recipe to follow and instead we got to build our eight weeks into what we wanted. What do you want to improve or what do you want to get better at? Let’s document that and make it happen. I think that is what I enjoyed the most. We all had something different in mind. And it worked. We had the freedom to build our community. What is your message[that you wanted to communicate to your community]? We were free to create our own program in a sense, but still be guided by two incredible leaders, Joe and Hector.

The experience

It was an incredible experience to meet other passionate students who are also volunteering their time to do amazing things. These twenty nine students were already encouraging and developing the next generation of young talent. These were people I wanted to be surrounded by. These students inspired me.

The program taught me the importance of public artifacts — about leaving a paper trail — and to start building myself and my career. “All the little things you’re doing now is building up to where you’re going to be”. — Brandon Keepers.

Overall, I couldn’t believe the incredible amount of training and mentorship I got from GitHub staff. I became conscious of the reality that people are the foundation of community.

Being a part of the GitHub Campus Experts Program, I was given the right tools and support I needed to help other developers. I felt like I had been given a secret weapon. And after the eight weeks, I was more than ready to take on the world knowing I had this secret weapon in my back pocket..

Postscript

I can eagerly say that I have grown my network of support and I feel much more prepared for the next challenge. I found my sweet spot between community and technology. GitHub Campus Experts gave me the push I needed to take the next steps in my path.

The program pushed me outside my comfort zone and with great results. I participated in my first ever Hacktoberfest and jumped into the amazing open source community. I also got to make my first ever video tutorial on something I had only began learning a few weeks prior. I even got featured on MLH’s Local Hack Day YouTube channel! Most of all I got to make new friends and new mentors.

Everything I had been doing in the past months, going to hackathons, going to meetups, organizing tech events, etc. allowed me to build myself. And more importantly it allowed me to fall in love. I fell in love with being immersed in a culture that focuses on learning, building, and sharing.

The GitHub Campus Experts Progam is fostering communities that promote learning, building, and sharing in technology on a global scale. — Kim Noel

Today, I can proudly say that I am a contributing member to the support system in the tech community that Keepers was talking about. And I’m not going anywhere any time soon.

Thank you Joe, thank you Hector, thank you John, thank you Brandon, and thank you GitHub! ❤

Do you enjoy organizing, planning, and bringing people together? Do you want support and help running events? Do you want access to resources and advising? If you want to be a part of a growing community who is making a long-term and positive contribution to the future of tech, then this is the place for you! Become a GitHub Campus Expert today https://education.github.com/experts

This write-up is intended for those who have never been to HackCon (US) before and are wondering what they can do to make the most of the weekend. If it’s not your first rodeo feel free to skip this one... or read through and send me a shout on stuff you think I may have forgotten!

Let’s dive right in.

Pregame

Mindset

You’re about to meet 300–400 people. Are you excited? Are you nervous? Having the right energy and the right attitude is key to getting the most of the event. You want to go into the weekend with a positive and collaborative attitude. After all, you’re all there because you believe greatly in building up your hacker community and making it the best possible one for students. There can be some uneasiness when thinking about meeting that many people, which can hinder your ability to get the most out of the event. So, a good way to shift your attitude positively is through the act of preparation — focusing on your outcomes/goals.

Preparation

It’s easy to get caught up in the hype of being surrounded by hundreds of other like-minded students. The simple act of writing out what your goals are can help can move your attitude in the right direction. Try to sit down and visualize what would you like the outcome to look like. What are you hoping to get out of HackCon? Maybe you are just looking to find out more general information about hackathons. Or maybe you want something more specific like creating more inclusive events, hosting other events to complement your hackathon, tips on fundraising, etc. Take a look at the schedule. Which sessions look interesting to you? Think about what you’d like to get out of each one, this doesn’t have to be the same as the main takeaway. Meet with your team before jetting off to New York. Maybe not all of you get to go and it’s good to find out what information they would like to gain as well. It’ll not only be what you want to get out of the event but also your team.

By being well prepared and enthusiastic you will be able to create the confidence you need for a successful HackCon. Let’s move on to some advice you can take on during the weekend.

Show time

Divide and conquer

If your team is fortunate enough to send more than one person to the conference, make sure to have a game plan. Don’t all go to the same session. Split up and attend as many different ones as you all can. If two of you want to go to the same session, make the tough call and appoint only one of you. Write down points you want to bring up or information you want to gather and hand it off to the other person. Cover as much ground as you can.

Participate

Not only is it great to hear other people’s perspective, but it’s also a great opportunity to share your stories and experiences. This may seem evident, but it’s easy to want to sit back and hear what everyone else has to say, especially if everyone sounds like they have more experience than you. Don’t let this fool you. Your fresh perspective can bring a lot to the table. Your voice matters! We want to make hackathons the best they can be and that’s going to differ from community to community and from the various levels of experience. Making better hackathons is going to stem from your input, so put it out there!

Connect

I’m going to challenge you. Make at least 5 meaningful connections. This connection could be someone who ran a cool workshop and you want to sync up to get tips, someone who’s written a lot of posts online and you want to read/hear more, or just someone who loves the same board game as you. With that, try to swamp knowledge with other attendees. You are good at X and can help them with that or you need help with X and they can help you with that. While meeting attendees, make sure that includes meeting the sponsor reps — the ones who attend this event are pretty gung-ho about helping your communities. They are looking to find out in what ways they can help and are looking for have you contribute to their company as well!

Random Kim Tips

• Bring stickers!! Sticker swamping is hella fun.
• Don’t bring a lot of clothes, but do bring warm clothes… you know the old saying, you can always take off layers.
• Please do not be cliquey!! Big events like this can foster pack mentality, but I strongly urge you to not fall into that. I know you love your fellow organizers and hacker group, but break off and meet other people. When you stick together it can make it difficult for others to approach your large group.
• Check twitter for #hackcon and see what people are talking about. Tweet about why you’re excited and let other people find you :)
• Take notes! I made a conference note taking sheet template, feel free to use it. You can find it here.

Don’t forget to live in the moment! At the end of the day, our experiences and the relationships we build are what we are left with. Make the most of this opportunity — connect, create relationships, and LEARN from other student leaders.

I’d love to hear from you! What are your tips for preparing for this type of conference/event? Leave your feedback/comments below ↓

Teaching anything online through a video tutorial is a super useful resource. It’s great for those looking to dive into a new technology or someone who is stuck on a technical problem and looking for a well-explained solution. Whenever I would watch video tutorials, I would often find parts missing/skipped over. That’s why I wanted to start doing workshops and making tutorials — I wanted everyone to have a chance to learn whatever they wanted and not have to endure the hurdles that can come with learning something new.

Here are a few things I learned from making my first one.

Before the camera is rolling

Research

Take a peek around on forums and blogs to see what common problems people are having. Try to pinpoint the areas people seem to need most assistance and that way you can better craft your explanations. That will give your tutorial the edge it needs to be a hit!

Plan

No such thing as freestyle when creating technical video tutorials. Jot down some key bullet points that cover the main components. Keep that list in front of you while you record. That way you can refer to it quickly and you don’t miss anything important. Avoid writing out entirely what you want to say — you want to sound natural! And most of all, make sure to practice, practice, practice. At least a few times before recording — this way you test out both your voice and the flow of your content.

Keep it fresh

Best tip incoming in 3..2..1.. clear your desktop! The best tip I got was before you press record make sure to clear the clutter on your desktop (if you have any). While you’re at it, close all programs and folders that are not needed for the tutorial. You don’t want any distractions for the viewer. Double check your wallpaper — make it something you would feel comfortable showing at school or at work. And lastly, any folders you need to open during the tutorial — de-clutter those too. It’s just eye pleasing to see an organized, clean workspace and it’s double great for making sure you don’t show any personal information.

While the camera is rolling

The Right Mic, The Right Mic, The Right Mic

Most laptops have a built-in mic and people think that’s good enough for recording videos. News flash, it’s not! They are ow-quality mics so they are not clear and tend to capture the sound around you instead of your voice. It took me a while to find a good mic, and even then it wasn’t all that great. The truth is bad audio can ruin the best of videos. So test out different options to find the right one for you. Leave a comment down below if you have suggestions for a great mic (within a student’s budget).

An Optimized Acoustic Environment

The earlier section kind of touched on this, but it’s important to explicitly mention it — beware of background noise. Even the typing of your keyboard can be a real nuisance. Make sure to turn off any fans, heaters, or other devices that produce ambient noise.

Balance

Know the right balance between humor, colorful, and dry. Some people try to drop in humor and it just comes off ‘cringy’. It can be unappealing and can really turn folks away. It’s okay to provide anecdotes and examples to highlight your point as long as they are not overpowering. A good frame of reference is would you be comfortable saying this in class or at work? Avoid stories/examples that have a negative tone and do not use humor that can be classified as crass or self-deprecating. Most of all, don’t forget to have some excitement when you speak! If you’re not excited about what you have to say, other people certainly will not.

After the camera is rolling

I’m a big believer in experimenting. See what works and see what doesn’t! It’s okay to put out a not top-of-the-line tutorial. Every pro was once an amateur. But do have one or two people test it before releasing the tutorial. Getting as many different people’s feedback is great. Just because it makes sense to you, it may be too difficult for someone else. We all learn and understand differently so try to be as open-minded as possible and understand that your tutorial might not be a one size fits all and that is okay!

Roundup

All in all, I hope that these tidbits can help at least one person get over the fear of putting something online. I feel fortunate to have gotten over the worrying and the need for something to be ‘perfect’ in my eyes before releasing it into the wild. I also developed a true appreciation for those who make videos as you quickly realize the amount of hard work that goes into them. It requires a lot of time and patience. So hats off to all those putting together tutorials!

So I’m checking off successfully tearing down the first pillar — concurring the fear of putting something online and I’m off to my next challenge, consistency. And continuing to do so on a regular basis!

A hackathon is an event where people from all kinds of backgrounds (not just Software/Computer Science students) come together to collaborate on technology projects. It is an opportunity to learn and meet new people.

The thought of attending a hackathon can be scary, especially if it is your first time. On top of that, if you plan on attending on your own you may be feeling really nervous. You are not sure what to expect or how to prepare. Will your skills be up to par? Will anyone talk to you? This article will answer those questions, but a quick peek → the answers are yes and yes!

Breakdown of a Hackathon

Note: Most of this is based off of MLH hackathons.

Start: First thing to do when you arrive at a hackathon is to head straight to the registration desk. Once you sign-in you either head to find a hacking space, go to an opening ceremony or browse sponsor tables. Some hackathons have a team formation session where you can meet other people looking for a project/team. Sometimes they offer pitches — you stand up and explain what you want to work on. After all the pitches students are free to approach you and ask to join your team.

• Opening ceremony: The ceremony usually lasts 1–2 hours. It will contain things like an introduction/welcome, main sponsor speech, a run through of the schedule from beginning to end, a run through of APIs and challenges offered, a run through of the code of conduct, a run down of how projects should be submitted, how/when/where judging will take place, etc.
• Sponsor tables: Depending on the hackathon, there may be more than one sponsor and they may be on site to get to know you! Recruiters will be seeking candidates for interns or fulltime. The best approach to strike up a conversation with them would be to ask them what their companies does, what positions they are looking to hire, where they are located, etc. They will either take your CV or redirect you to apply online… and most likely they will be giving out swag (t-shirts, power banks, waterbottles, pens, etc.)
• Hacking spaces: Depending on the hackathon, it could be classrooms (so try to find a quiet room), it could be in a huge gymnasium (try to get a spot away from any speakers — there will be frequent announcements and that can be loud/annoying right next to you) or it could be in an office space.

Middle: Sometimes you don’t find a team at the beginning and that’s okay! I’ve seen people switch teams or start a team from scratch halfway through the event.

• Food: Most likely the hackathon will be providing snacks (granola bars, fruits, juice) and at minimum lunch/dinner if it is overnight. To be safe, I would bring some snacks along in your bag in the event that they do not provide snacks in-between meals (if they do provide meals)… or you might be picky like me and not like the snacks provided.
• Hacking: This is the time where you are making the magic happen!
• Activities: Some hackathons have activities to give you a break from coding. These activities can include things like a silent disco, a smash bros tournament, a rap battle, dog therapy, etc. Take advantage of these — coding 24 hours straight is never a good idea.

End:

• Project submissions: Most likely you will be submitting your project on DevPost or a similar system. Make sure to submit your project on time — a good tip would be to setup the project on DevPost and fill in the blanks later. That way, you are guaranteed not miss the deadline.
• Judging: Usually happens in one of 2 forms: science fair style or pitches. Science Fair style is exactly how it sounds — you are assigned a spot at a table and everyone is present and showing off their project while judges/sponsors come by. For pitches — judges are setup in a room and teams are brought in one at a time to show off their project.
• Closing ceremonies: Similar to opening. Thank yous, announcing of winners, and good-byes!

Before the hackathon

1. Research the hackathon — There are different types of hackathons, while some are specific to resolving a challenge, others are more general and open. Amongst these are University/High School hackathons. Many of which are under the umbrella of the Major League Hacking. So before attending, understand what the nature of it will be.
2. Install shit — Download some IDE if you do not already have one. If you want to work on something web related then do some research on what a good IDE for developing for web (for example Sublime, Atom, Brackets, etc). It will help you save time during the hackathon, specially if the IDE is a few gigs. You cannot rely on internet at the venue — you never know the quality, it could go down unexpectedly.. I’ve seen it all!
3. Checkout APIs — You don’t need to know what exactly you want to work on, but it wouldn’t hurt to investigate your options. Do some simple research on which companies are attending and if they are providing their APIs. Some of these APIs require you to have done a bit of setup, so if you know you want to work with API xyz that requires you to have abc installed, then get a head start and install it.
4. Prep your bag — Make sure you pack the necessary items you will need for the weekend! Check out my checklist at The Ultimate Hackathon Packing Checklist

During the hackathon

The Do Nots

1. Work alone — Take advantage of the incredibly passionate people around you! Who else would dedicate their weekend to building something? So don’t be shy to get outside your comfort zone!
2. Bite off more than you can chew — You only have a short period of time to get things done, so try to focus on implementing a few set of features. You can always continue working on the project after the hackathon, which I strongly encourage you to do so!
3. Think you can’t contribute — Everyone brings unique skills to a team and all members need to contribute to be successful. Figure out how you can contribute to the team and focus on that part of the project.
4. Think pivoting is a bad idea — Successful hackathon projects often pivot from their original idea. If you think you’ve discovered something even better, or more useful during your project, switch gears and focus on that instead.
5. Cheat — A major issue with hackathons is that it can be very difficult to ensure participants are not “cheating”. Cheating at a hackathon can take on, but is not limited to, the following forms: working on a project prior to the event, submitting someone else’s work as your own hack, etc. Just don’t do it. Stay home. It defeats the whole purpose of the event.

The Dos

1. Be curious — It allows for possibilities and can lead you to many new opportunities.
2. Attend workshops — The learning you get in a 24-hour hackathon can be much more than you get in your first year of university. Take advantage of this.
3. Participate and explore — Don’t be shy to sit back and learn about other people’s projects.
4. Stay hydrated — Water helps transport nutrients to give you energy. If you’re not properly hydrated, your body can’t perform at its highest level… fatigue, muscle cramps, dizziness, etc. So try to drink lots of water!
5. Take breaks — A change of scenery can help you get the creative juices flowing and get inspired. Get up, walk around, see what other people are working on, get to know the companies there, etc.
6. Sleep — No one is going to stop you from an all-nighter... but they aren’t necessary. Again, be smart. Get some shut-eye even if it’s just for a few hours.
7. Network — Talk to sponsors, attendees, judges, organizers, volunteers, etc. You never know what may come out of it! You could get a new friend, a cool mentor to help guide you in your career, or even get an idea for the next hackathon you participate in.
8. Bring your resume — Fix up your resume and bring a copy or two along with you. There is the possibility of impressing a recruiter enough to get to interview at their company.
9. Learn — Aim to explore new technologies and learn something new. Maybe even learn some presentation skills along with the hacking skills!

Final comments

At the end of the day, hackathons aren’t for everyone.

Your best bet is to go in with an open mind and have an idea of what you’d like to get out of it. If you do not go in with some end goal, then there is no way for you to know the benefit of the event. Go to a hackathon because you want to talk to people, you want to understand challenges, you want to write code, and you want to have fun. Learn from awesome developers, learn how to work in a team, and be challenged to create something from nothing!

What is this tutorial for?

Today, we will be creating our first atom plugin. We will be creating a plugin that implements the basic functionality of a dictionary lookup. It will allow a user to search a word directly in the editor, by either highlighting the word or placing the cursor somewhere in the word. You can follow this post along with the YouTube video here.

What is Atom?

Atom is a free and open-source source code editor developed by GitHub. The editor is meant to be customized in every possible way. It is built on a Chromium browser with HTML, Javascript, CSS, and Node.js and has complete access to the standard developer console window in Chrome.

Creating an Atom Plugin

To get started building your first Atom Plugin, you must have Atom installed. If you do not already have it, go grab it for free from their website: https://atom.io/

So, let’s get started with our first plugin!

Package Structure

Atom stores all it’s plugins within the atom folder, .atom. It is located at \Users\user-name\.atom. Within the folder, there is a subfolder called packages. Which, as you may have guessed, is where all the packages can be found. Every package has its own folder.

The first step is to create a package for the plugin. I will create a folder called kims-dictionary-plugin.

Depending on the type of package you want to build, you may not require all these folders (or you may require additional ones). Nonetheless, this gives you a good breakdown of what a basic package structure looks in Atom:

my-first-plugin/
├─ keymaps/
├─ lib/
├─ menus/
├─ spec/
├─ styles/
└─ package.json

Now let’s take a look at some of these folders and files.

package.json

For our package to be recognized by Atom, we need to add a .json file: package.json. This json file will contain metadata about the package and is based off of the regular Node package.json keys (https://docs.npmjs.com/files/package.json).

A general structure and important keys to implement are as follows:

Keys explained..

• name is the name of the package
• main is the location of entry point to the plugin, kind of like main (usually located in the lib folder named as plugin-name.coffee.. and if the main key is not in your package.json file, Atom will default to looking for an index.coffee or index.js file)
• version is the version number of the package, and must follow the convention: major.minor.bug (you should indicate 0.0.0 for now)
• description informs others about what the package does
• engines indicates the minimal required version of Atom
• dependencies indicates other packages needed
• repository is a URL indicating where the public repository is located
• bugs is a URL where others can report issues
• license indicates the license

Some other keys…

• styles: an Array of Strings describing the order in which your style sheets need to be loaded (if not specified they will be loaded alphabetically)
• keymaps: an Array of Strings i describing the order in which your key mappings need to be loaded (if not specified they will be loaded alphabetically)
• menus: an Array of Strings describing the order in which your menu mappings eed to be loaded (if not specified they will be loaded alphabetically)

There are many other keys, however for now this is as much as we need to create our plugin.

Now that your package has a valid package.json file, Atom can recognize it and load it. However, it’s totally useless right now. So, it’s time to make it useful by giving it some features!

Note: Code snippets will be written mainly in EcmaScript standard for JavaScript.

Package logic

Our package logic can be found at plugin-name.coffee/.js.

• your-plugin.coffee/your-plugin.js handles the logic of the plugin and can be viewed as the main package file
• your-plugin-view.coffee/.js handles the UI elements of the package

In your main, you usually have the following 3 methods: activate, deactivate, serialize.

• The deactivate method destroys the various class instances created
• The serialize method passes on the serialization to the View class
• The activate method is what is executed when your plugin is loaded and instantiates the view class.

Here is an example skeleton for my-first-plugin.js:

Code explained: Commands are events triggered by a user and packages can subscribe to commands. By subscribing, they can execute code in response to the event (a.k.a the command) that was triggered by the user. When we want to subscribe to multiple events that’s where the CompositeDisposable class comes in handy, but we won’t get into any specifics right now.

The toggle method is what gets called every time the user wants to run the package (‘toggles the package’). It is invoked either by the menu item or a hotkey.

Here is an example skeleton for my-first-plugin-view.js:

Adding Code

So let’s dive in. First, we want to grab the word we want to lookup.

We do this by creating an reference to the current state of the editor and finding the word that is either selected or where the user’s cursor is. We will add this snippet to our toggle method. Also, don’t forget to define the variable wordToSearch:

wordToSearch: null,

Next, we will add a method in our view to update itself.

In our view, the root element only had one child (index starts at 0) and we want to update it’s text to reflect the word we just grabbed from the editor. Afterwards, we will need to go back into our logic and add the following line:

this.MyFirstPluginView.setElement();

With this line, we will call the setElement method we created which will update the element with our word.

At this point, you may notice that as you make changes to your package the changes aren’t reflected right away. You need to reload Atom, either by closing and re-opening or hitting View > Developer > Reload. This will ensure Atom runs the latest version of our source code.

Therefore, reload Atom and toggle the plugin. The panel now displays the word where the cursor is focused or highlighted.

Let’s take a moment to look at the flow of our package in Atom:

• First, Atom starts up.
• Second, Atom begins loading packages.
• When Atom reaches our plugin it reads the package.json
• Atom is going to load in our keymaps, menus, styles and main
• At some point in time while the user is using Atom, uur package gets toggled your-plugin:toggle
• Once our plugin is toggled, Atom executes the activate method. The activate method sets up the UI by creating a hidden view and then executes your-pluggin:toggle which reveals the hidden view!
• Lastly, when toggle is called again Atom executes the toggle command again which hides the view.

Connecting to an API

Now, we will need to connect our plugin with some sort of Dictionary API. For this tutorial I have chosen the Oxford Dictionaries, but feel free to use any Dictionary API that your comfortable with.

This may not be the most efficient way to put through a request to the API and process the results, but here is how I did it:

I send an XMLHttpRequest to the API by providing my credentials and adding an event listener to the request. This event listener, when it receives a notification that transactions has been completed, it will parse the results (which is in JSON format). The results I get back contain a ton of information, however all we need for the sake of this tutorial is the first definition returned.

For now, we will place this logic in our toggle method. Don’t forget to define our variable that stores the definition:

wordDefinition: null,

We will need to update our view to reflect the new changes we made.

Reload atom and toggle again… Volià!

You did it. Your first plugin, check!

I went a head and added some CSS under the styles folder.

You can find the link to my repository here: https://github.com/kim-codes/kims-dictionary-plugin

Take it for a test drive, add some functionality, improve on it.. but most of all enjoy :)

In less than 5 minutes

For this example, we will be using GitHub Pages for hosting. Checkout my article called I want a website. Now what? to understand what hosting and domain names are. Since we are using GitHub Pages, buying a domain name is optional. If you do not purchase a domain name, then the URL to your page will simply be github-username.github.io. Also, there is no limit to how many “sites” you can host on GitHub Pages if you use the project pages method.

Steps:

• [ Optional ] Buy a domain name
• Create a GitHub account and create a new repository
• Create content
• [ Optional ] Setup your domain name

[ Optional ] Buy a domain name

Navigate to your preferred site for buying domain names. Here I am using Namecheap, however feel free to use any domain name purchasing site.

In the search box, Find your new domain name, enter the name of the site you’d like to purchase. Here I typed “kimcodes.tech”:

As you can see kimcodes.tech is already taken (I bought it). However, there are many other options available like kimcodes.xyz, which is only $1.15 CAD for the year. Not bad! Once you find the domain name you want, within a price range you’re willing to pay, simply add the domain to your cart using the add to cart icon:

Follow the checkout process and the domain name is yours!

Side note: Buying a cheap domain like .xyz for $1 isn’t always the best choice, because you need to take into consideration the renewal fees for the following year. So you will need to weigh the pros and cons.

Create a GitHub account and create a new repository

Once you have a domain name you need to setup the hosting. Hosting is where you will store the code that generates your site. For this tutorial we are going to use GitHub Pages.

Head over to www.github.com and create an account if you do not have one.

Once signed in, you will need to create a new repository. If you are on the main page there will be a green button in the top right corner that reads “New Repository”. If you are on your profile page, you will need to click on Repositories and then hit the green button on the top right that says “New”.

Make this repository Public and name it as github-username.github.io. My GitHub username is bacontext so my repository name is bacontext.github.io.

Create content

The repository you just created will store all the files needed to generate your website. For now, create a file called index.html in the master branch. By default, when you create a new repository there will be a master branch. A separate article will be written on how GitHub works and how to use it. Add the following snippet to your index.html file:

<html>  
    <head>    
        <title>My First Site!</title>  
    </head>  
    <body>    
        <p>I created my first web page using GitHub Pages! </p>
    </body>
</html>

Your index.html file should look like the following:

Hit Commit New File. Navigate to your URL, github-username.github.io, and voilà!

Now that you get the idea, you can use one of the 12 themes crafted by GitHub designers and developers. All you have to do is head on over to the Settings tab of your repository, scroll down to the GitHub Pages section, and click the Automatic Page Generator button. Pick one, publish, and again voilà!

If you bought a domain name, there are additional steps to follow.

Setup your domain name

While in your repository create a new file called CNAME. In this file write your domain name. You may only write ONE domain name so if you have multiple there will be some extra steps to have them all redirect properly. Your file should look something like this:

Once you save your CNAME file, click on Settings in the current repository. Scroll down to GitHub Pages and enter your domain name in the Custom domain section. Hit Save.

If you used Namecheap to purchase your domain name you will need to perform the following steps on the Namecheap website:

• Sign-in and click on Domain List.
• Click on the Manage button for the domain name.
• Select Advanced DNS. Then you should see Host Records section.
• Delete the two default records (URL Redirect record, CNAME Record).
• You will need to create three new records for your domain.

These host records point your domain to the IP address of your hosting, which in this case is GitHub.

** UPDATE ** September 2018

1. Add a new record. Select “A Record”, set the Host to “@” and the IP Address to “185.199.108.153”.
2. Add a new record. Select “A Record”, set the Host to “@” and the IP Address to “185.199.109.153”.
3. Add a new record. Select “A Record”, set the Host to “@” and the IP Address to “185.199.110.153”.
4. Add a new record. Select “A Record”, set the Host to “@” and the IP Address to “185.199.111.153”.
5. Add a new record. Select “CNAME Record”, set the Host to “www” and the IP Address to “your github-username.github.io”.

If you look up the IP addresses you will see they belong to GitHub. Save all changes. It should look something like the following:

* NEW **

Head back over to GitHub settings and Enforce HTTPS

** IMPORTANT **

Note: If you are updating your previous records, you may need to delete the CNAME file from your repository and re-add it. After which it could take a few hours for your site to be https secure.

It can take a full day to update and the wait varies among DNS providers, for the newly created records to take effect.

I hope you found this tutorial useful! Next time I will show you how to use free Azure credits to host your website. Stay tuned.

So you want to put up a website. What is the transition between wanting a website and actually having a website? You’ll need to buy a domain name and purchase hosting. What is the difference? What is a domain name? What is hosting? And why do you need it?

A domain name identifies a webpage much like a store name identifies the store. John’s Tools is the name of the company that sells tool. John’s Tools also has a website, and their domain name is www.johnstools.com . Pretty simple, right? You want to communicate with an online store called John’s Tools and their shop is listed at www.johnstools.com.

Alright, so you bought a domain name. Now what? This is where hosting comes in. Think of a domain name as the name of your store. So you registered and bought the company name, John’s Tools. Cool. But now you need to rent out physical space to host your actual store. Similar to a physical store, you need to rent out space somewhere out there on the internet. The physical space you buy for John’s Tools is empty. Just like when you pay for hosting, you are given a certain amount of empty storage space. For John’s Tools scenario, the physical space will contain the content which he wants to sell. For our site scenario, the space will contain our files like .html files, .css files, .js files etc. and these files will generate our webpage.

So how do you get started? What are the next steps?

GitHub makes it easy for you to get a personal site up within minutes. They provide you a personalize url that is tied to your account. Feel free to look into it more at https://pages.github.com/. Stay tuned for my next article on Setting up a web page with GitHub Pages.

Transit App: Real Time Tracker

Making sure you get to class on time! Based on a metro station or location the app will show you all the nearby bus routes + metro lines and when the next one is passing. It also pre-loads maps and all transit schedules so you can use it on the go with no wifi or data connection.

Transit App: Real Time Tracker - Android Apps on Google Play

For Apple users navigate to the iTunes store for the Transit app here.

Google Keep

Good for short notes and checklists. Since it is linked to your Google account the notes and lists are synced across your devices. All you need to do is sign in with your Gmail!

Google Keep - Android Apps on Google Play

For Apple users navigate to the iTunes store for Google Keep here.

Kanban Task List

A great app for keeping track of your Todo list. Very similar to Trello, but a simplified version with only three columns; Todo, Doing, and Done. No custom columns. If you are an advanced user Trello is great, but for those who do not need as much flexibility and customization Kanban is a great alternative.

Kanban Task List - Android Apps on Google Play

Student Agenda

To-do manager catered towards the life of students. This app includes a grade tracker and study session reminders. Navigation is a bit tricky at first, but is simple enough to pick up after a bit of trial and error.

Student Agenda - Android Apps on Google Play

Discord

The solution to large group projects. Skype and hangouts calls too choppy? Discord has set out to solve that issue by hosting the call on another server, so as to not rely on a single person’s connection. It is not just for gamers! A great messaging and group calling client. You can chat with friends and organize bigger group chats with fellow students.

Discord - Chat for Gamers - Android Apps on Google Play

For Apple users navigate to the iTunes store for Discord here.

Slack

Keep track of group projects much easier with Slack! Slack is a messaging app from desktop to mobile. You can break down projects into channels to allow for better organization. It has tons of plug-ins too so you can sync everything to one place! Plug-ins include Dropbox, Google drive, Trello, Github, etc.

Slack - Android Apps on Google Play

For Apple users navigate to the iTunes store for Slack here.

Tiny Scanner

Simple and straightforward app. Great for converting pictures into PDF and then send them as an e-mail attachment or uploading to a service like Dropbox or Google Drive.

Tiny Scanner - PDF Scanner App - Android Apps on Google Play

For Apple users navigate to the iTunes store for Tiny Scanner here.

My Data Manager

Since I only have 500mb plan not going over my limit is vital. When you first install the app it will ask you how much data is included in your plan. It will say zero data used so far this month so you will have to manually enter the amount of data already used that month.

My Data Manager - Data Usage - Android Apps on Google Play

For Apple users navigate to the iTunes store for Tiny Scanner here.

Share with me your favorite free apps!

A hackathon isn’t about staying up 24–36 hours straight, building a software project, and winning some ultimate prize. It’s not. So get that out your head. Let’s just start by slashing some myths:

• You ‘hack’ software
• You have to know how to code
• You have to be a coding wizard
• You have to be in Computer Science or related field
• You have to stay up all night, eat pizza, and drink energy drinks
• You have to have a team before the event
• You need to create the next Facebook

1. You ‘hack’ software — We are not breaking into the NSA. No illegal shit goes down.
2. You have to know how to code — One time I went to a hackathon and did tutorials to learn a new language. We ended up making a really dinky app, but we got to learn how to develop in Android. We also played with new tech gadgets that we otherwise would never have had the chance to. Where else are you going to get to try the new Oculus Rift or use a Leap Motion?
3. You have to be a coding wizard — Where is this standard coming from? You don’t know anything? Good! Sit down and learn some Java, CSS, NodeJS, etc... Anything at all. I dare you.
4. You have to be in Computer Science or related field — I’ve met people from Mechanical Engineering, from Med, from Philosophy, from English literature… should I go on?
5. You have to stay up all night, eat pizza, and drink energy drinks — At MHacks, my team made top 10. We slept a decent number of hours both nights, we participated in fun dancing activities, and we attended workshops/talks. Stop it with the all-nighters already.
6. You have to have a team before the event — Although most hackathons organize a pre-event (virtual or in-person) meet and greet type things for you to get to know other attendees, this isn’t entirely necessary. I personally find it misleading. This implies that if you don’t have a team, you’ll end up alone and having a terrible time. I traveled 7+hours to Philadelphia (PennApps), alone, not knowing anyone, and ended up forming a team a few hours after the event started. I survived.
7. You need to create the next Facebook — My team and I at MHacks built an automated syrup dispensing machine. Check it out; it was pretty awesome (video here). At McHacks, my team and I built an automated nerf gun, you can see a video of it in action here. I knew zero zip nilch nada about hardware. Who says you can’t have fun while learning? Stop thinking you’re going to build a startup (although some people do create a business out of their idea), this isn’t the case 90% of the time.

The problem is the way hackathons are painted for you. What if I told you you can go away for a weekend, travel for free to a place you’ve never been before. You’ll explore a new city, be surrounded by some incredibly intelligent people, who by the way are more than willing to help you, be fed, be given t-shirts, battery chargers, etc., and learn how to code? And/or get to play with a hot new technology? Doesn’t sound so bad, eh? One of two things can go down: 1) you start a project during the weekend or 2) you obtain the knowledge to start a project. Either way, you’ll get what you need to get something off the ground and add to your CV. Side projects are great for landing you a gig, because it shows initiative and shows you’re passionate.

I cannot stress how little you actually need to know to go to a hackathon. You just need to have an eagerness to learn. Many times people have told me that they have not gone to one, because they “don’t feel ready” and are super intimidated by the competition aspect of the event. Hackathons are for learning. And this needs to be emphasized. If it remains intimidating then, as organizers, we are doing our job wrong.

Hackathons debunked! was originally published in HackConcordia on Medium, where people are continuing the conversation by highlighting and responding to this story.