Being proactive is a crucial trait for any developer (and particularly important for a remote and/or junior developer). The last thing a company or a team wants is a developer who is always waiting for someone else to give them tasks or tell them what to do. Being proactive means thinking about the future and focusing on the things you can control instead of all those you cannot.
While there are many things you cannot control while building your career in Tech (i.e the condition of the job market, the willingness of companies to hire junior devs, the years of experience required by your dream job, etc) there are many other things that you can control. Becoming a proactive developer is one of them.
- Why is proactivity crucial
- Words are not enough
- Working on projects
- Frequently asked questions
If you’re a development manager or a CTO (in a couple of years) and you want to do your job well, you need proactive developers working for you. Else, you’ll constantly have to hand-hold people, give approvals for the smallest things, assign new tasks, unblock people, etc. You’ll barely have time to do anything else! CTO’s and development managers want to focus on helping developers grow instead of pulling them along from task to task. For that, they need proactive people.
Companies are particularly concerned about proactivity when it comes to hiring junior developers. Non-proactive junior developers have a hard time growing into their role and most important of all, they sometimes require too much time from their more experienced team members to do the job. When you are being interviewed for a junior role, it is very important to prove that you are the proactive kind of developer!
Proactive developers can’t sit still. They hate being bored and can’t go without a task or a project for long. They’ll create their own tasks if none exist. They’re the developers who are never blocked and will either find ways to become unblocked or find ways to add value until they’re unblocked. Proactive developers are the ones who finish sprint items and then ask their team if anyone needs help. They constantly move projects and teams forward!
The same happens with proactive students: They can’t sit still! They read about coding and technology; They improve their communication and teamwork skills; They work in projects to improve their coding style and portfolio, to challenge themselves and to be more experienced at the time of graduation. These are the students that find jobs faster and build great careers for themselves.
To be successful in software development (especially as a junior developer) it helps to take initiative. This means going ‘above and beyond’ what is asked of you and making sure that things are done correctly and on time (indeed one of HackYourFuture’s core values).
Roughly all of HackYourFuture students claim that they are REALLY passionate about coding. They share with classmates, with mentors and with interviewers that they’ve found a new passion with HackYourFuture. We think this is AMAZING!
However, when presenting yourself to real interviewers, saying that you are passionate, or saying that you are proactive is not enough. You need to show how you are passionate and proactive. And the best way to do just that, is to actually work on projects next to your studies/work to show interviewers/recruiters/devs at the end of the program what you are capable of building.
But you might think...building more projects next to the program? Who has time for that? The answer is easy: Can you imagine a passionate and dedicated football player that doesn't play much football; Or a passionate piano player that doesn't play piano? Same applies to you: any recruiter or company would expect a passionate, proactive and dedicated web developer to build web-development projects.
Working on projects next to your study will help you to better understand concepts, improve your CV and portfolio (to get you hired faster) and most importantly will get you in a position in which being proactive is the only way forward: If you challenge yourself with projects, you will have to come up with ideas, seek for feedback, implement that feedback, and more.
Companies expect entry level job seekers to not only write clean code and communicate well but also to already have some experience and a portfolio of projects. We will be building some projects during the curriculum, but having extra-curricular projects will help speed up the process to finding a job. A student that has extra projects in their portfolio before the end of the curriculum may be considered for an earlier graduation which will lead to getting into a job sooner.
The projects in your github should reflect your skills at the end of the program, and include enough features and refinement to show the HYF team and future employers what you can build by yourself. Below we will give some ideas on what you can build.
This would be a project to which you can keep adding to as you learn new things in the curriculum. Starting with a vanilla JS frontend with fake data, then building a backend without a database in Node, then adding a database in Databases and finally converting the frontend to a React frontend. It is tempting to wait until you know everything before starting this project but we think it is a good idea to have a running project that you can keep adding to. That way you not only have a nice and practical way of using the concepts you learn throughout the curriculum but you also get a feeling on how a project evolves over time. In the end you will rewrite a lot of the code but that is totally fine, ask any developer and they will say that they write at least 5x as many lines of code than get put into their final Pull Request.
Here are some examples that our students have built:
During the curriculum you will hear about different libraries or technologies that we have left out of the scope. A proactive developer will want to try these things out and think of an application where they can do that. We will give some suggestions for you during the curriculum but if you encounter something else then feel free to check with us if it would be a good technology to look into.
A try-out application does not need to be too functional and you should try to strip away as much as possible to really isolate the new topic you want to learn. For example if you are looking into GraphQL as an alternative to communicating via a REST API, then keep the app simple. A lot of developers use the good old Todo list as an example because it is simple, but it does require implementing all of the usual CRUD things. Or if you are working on a new way of writing CSS (looking into frameworks or SASS for example) then don't add any JavaScript. Also don't try to design something yourself, make the project a copy of a good looking website so that you can focus on the tech rather than spending time on design!
If you ever want to extend a try-out application but don't know where to go or you feel that the tech is not really adding something in your eyes then you may be using it for the wrong use case. If that happens then please send a message in the #get-help Slack channel with your project, a mentor there will be happy to help you get a better idea on where to go.
Here are some examples that our students have built where they experimented with something new:
A full stack application can be started after the Browsers module. In that module you will be building a simple application that will show you one way of structuring your code. That will help you think of how to start building an application. This will give you between 5-6 months to work on them, so we expect some great looking applications! Look at the curriculum planning for reference:
You can join a special Slack Channel named #get-help where other students and several mentors will be available to help you whenever you need some assistance in planning, building and improving your projects. You will have to be proactive in finding help from others in this channel by sending a message. This will be 100% your responsibility. Remember to make sure that your question is complete and gives an idea of what you need! For example, a question like:
My app is broken, what should I do?
will not get much of a response as it is very unclear what needs to happen. But if you add information for the others that allows them to have a quick look, they will be much more interested to help:
I was adding a React frontend to my app and whenever I run the app I get the following error:
build.js:196 Uncaught TypeError: React.render is not a function
at Object.2.react (build.js:196)
at s (build.js:1)
at e (build.js:1)
at build.js:1
Here is the repo with the error: https://link.to/repo
Additionally, you will be able to join tech hours held by mentors and the HYF team to get help with your projects as well.
The HYF team will do a final revision of all of your apps at the time of the graduation interview. We might ask you questions about what you’ve built and what you’ve learnt. For this, be sure your projects are deployed and added to your CV before the graduation interview.
Some of the things we will look at in order to see how proactive you were in building these projects throughout the program are:
- Have you requested feedback from others and implemented that feedback?
- Is the app working flawlessly and following all recommendations for technical assignments discussed throughout the program?
- Have you worked on these apps through the course of the program, or you rushed these projects at the end only to graduate?
- Are you following the Design Guidelines for HYF students' repo, the learnings from the UX workshop and the Technical Assignment Tips repo?
- Are the apps deployed, added to your CV and following the GitHub repo guidelines at the time of the final graduation interview?
Working in groups is totally fine, you can learn a lot from each other. Do make sure though that before you start interviewing everyone in the group has a copy of the code in their own GitHub as that is what recruiters will be looking at. You may be asked questions about these projects, so ensure that you understand all of the code.
Anything you want as long as one is a full stack web application and the other one, a try out application as mentioned above. Think of this as an opportunity to build something that you always wanted to have or to try out some technology that you wanted to learn. The project does not have to be groundbreaking, you don’t have to create the next Facebook. Just make sure it is something doable and that it looks good both on the outside as well as the code.
No they do not. The guided projects in the curriculum (HackYourWeather, HackYourRepo, etc) or the Browsers, Using API’s and React final projects do not count. This is about building something specific for you to challenge yourself and apply the concepts you learn in a real world scenario.
Preferably not. When following a video tutorial or code-along, you might overestimate your skills as everything is easy when someone has done the problem solving for you. You can use a video tutorial as a starting point, but make sure that you add your own twist to it. Also have a look at the following article about how to actually learn from these. The real learnings come when struggling building things by yourself and for that reason, following tutorials is discouraged.
- What do you know more about, or think more about, or do more of than your colleagues? Topics, apps, types of websites, tools... is there an interest you share or would enjoy to discuss with your classmates? They can help you build on your interest, literally!
- Find a friend or family member or alum who can hold you to account. Is there a topic they are interested in, where they also want to see what you build? For example, maybe they run a business and might like to have a website? Or you want show someone that you've been thinking about them: dedicate a web-project to them, as a digital gift!
- Is there a digital tool that might help you in your own life. Is it silly or exaggerated? Even better!
Discuss ideas with mentors and colleagues...There are plenty of options! Become a proactive developer by brainstorming or developing ideas with others until you find a project that gets you excited!
Steps in brainstorming and refining ideas can include: rapid-fire sticky-notes, find themes, elaborate, write an elevator pitch. Research, introspect, discuss. Once you have a topic, use a similar process to list functionality that you could build, by writing it down, like the author did about the pages of petplaats.
Set early deadlines, so you can stop talking and continue coding. Mock interviews usually take place a few weeks after you start your personal projects. Can you give the interviewers the elevator pitch or show them one of the functionalities? Then you get to practice showing off how you put learning into action, and how you solve problems.
On Slack you can find a channel named #get-help. In this channel, we have several mentors as well as other students who are able to help you out. Keep in mind that mentors have other jobs and are usually busy, so give enough time to get the feedback/input you need. Additionally, every week you can join different tech hours.