Good morning, good afternoon and as always good evening, it's that time of the week again for another instalment of The Rising Coder!
Thank you for coming to check out my blog again this week and I hope you can find this week's blog useful for going into Week 1/3 of the final Project Phase of the Northcoders Bootcamp.
But before that, be sure to follow me on Linkedin, Twitter and Dev.to to keep up-to-date with my journey both here at Northcoders and beyond as a Software Engineer!
So diving straight into the big unknown that is otherwise known as the Northcoder's Project Phase because it is heavily shrouded in mystery, but I hope that with this week's blog entry that I can demystify these mysteries so that you, the future Northcoders can confidently enter the Project Phase with confidence!
For those of you who are wondering what I've been up to this week, I've broken down everything into its own sections below:
- Careers Day - CV Writing Workshop with Keely Madgin
- Careers Day - Aceing Your Tech Test with Jim Stevenson
- Careers Day - Industry Insights with Mal Browne
- Careers Day - Presenting Yourself with Kathy Brooke
- Careers Day - Preparing For Interviews with Darren Holland
- Previous Technical Recruiter Tips & Tricks with Michael Whittam
- Introduction to the Project Phase
- Project Phase - Concept of Spiking
- Agile Standups (Meetings)
Careers Day - CV Writing Workshop w/ Keely Madgin
To start off this week, we had the long-awaited "Careers Day", which is an entire day from 9-to-5 dedicated to ensuring that we create a polished CV that's ready to be sent to future employers.
In order to gain access to Northcoders' personally curated job board, you will need to first create a CV that the Careers Team at Northcoders are happy with to send, but don't worry as you're assigned a personal careers advisor earlier on!
I won't get into complete specifics of the structure of a CV as there are an insurmountable amount of information regarding this, but will instead write a few summary points to think about when it comes to writing your CV:
Things To Consider:
- Why did you want to become a Software Developer in the first place?
- Why did you come to Northcoders? (Remember joining the course and perservering is already an amazing feat within itself and speaks volumes for itself, so really think about it!)
- What were you doing before?
- What makes YOU unique?
- What transferrable skills do you have that would help you FIT what a company is looking for?
Things To Avoid:
- Avoid clichés that are often thrown around such as "I am a hardworking person...", as that is the fastest way for a Hiring Manager or Recruiter to ignore your CV!
- Rambling on - If you write too much on your CV then you'd: run out of things to talk about, show that you can't be succinct and to the point.
- Listing skills in a table - Many templates will have some sort of tables and whilst this looks great, the reality is that recruiters/hiring managers process it through some piece of software. Therefore, to ensure your CV has the highest probability of being actually looked at, consider not writing details in a table!
- Giving yourself a subjective "rating" - This is a common cliché in CVs where you subjectively "rate" your own skills for example in React. AVOID THIS AT ALL COSTS - before you even have an interview, you have already planted a seed at the back of the interviewer's head and that's what we want to avoid!
Careers Day - Aceing Tech Tests w/ Jim Stevenson
Perhaps one of the most things that I'm personally nervous about besides behavioural interviews are the infamous "Technical Tests" or "Tech Tests" that are integral to landing your first position as a Software Engineer.
However, Jim's fantastic advice that focused on the single concept of: "Communicate, communicate, and finally communicate!" was at the forefront of his presentation, and made it significantly easier to follow his advice with complete confidence.
Whether you are thinking about "How do I break this problem down?" to the actual process of "Okay this is how I will break this problem down", make sure that you're talking aloud and communicating your thoughts honestly.
If you don't know something remember that is completely FINE and DO NOT be afraid to admit this and ask for help or if you're able to have a quick Google Search on the official documentation because this is what you would be doing on the job anyway!
With those precursors out of the way, the types of tech tests and advice that Jim provided are as follows:
On-Site Test
- Duration: Short
- Nature Of Test: Focused on seeing how you break down problems and communicate it in real-time with future team members.
- Common Style: Whiteboard & Pseudo Code - Focused more on writing down how you would proceed with breaking down the problem and writing pseudo code.
Take-Home Test
- Duration: 6-8 Hours
- Nature Of Test: Focused on seeing how you break down problems, how you structure your code, how clean your code is, and seeing how much you can do in a set time frame.
- Top Tip: Give yourself a strict time limit to do what the test asks for within those time restrictions. It demonstrates accurately what you can do with that time limit and you can adhere to time restrictions.
- Bonus Tip: If you did not manage to complete the test on-time, don't be afraid to write pseudo code to show what you were thinking of implementing if given enough time.
- MUST: Whenever you've finished a take-home test. Make sure to write a complete README detailing what you have done!
Careers Day - Industry Insights w/ Mal Browne
Mal's presentation on the industry insights provided a valuable sneak preview of the types of developer teams there are available and what we can realistically expect upon graduation.
Types Of Developer Teams
The three distinct types of developer teams that you can expect to work for are:
- In-House - This is where you work as part of a company's internal In-House Software Engineer team to build the core products/services of the company.
- Agency - You work for an agency that provides Software Development expertise to their clients and assist these clients with building technology.
- Consultancy - Similar to working in an agency, you will be responsible often for both providing Software Development expertise with coding AND professional insights and advice to clients.
Getting Hired As A Junior Developer
A few of the points that Mal pointed out that can help you get your first job as a Software Developer are:
- Attend as many events such as networking events and hackathons
- Even after the bootcamp ends, make sure you keep coding regularly to keep in form!
- Consider contributing to Open Source projects on GitHub
- Keep up-to-date with industry news & developments
- Setup a professional LinkedIn profile
Careers Day - Presenting Yourself w/ Kathy Brooke
The significant amount of value that this presentation was able to deliver was invaluable to me personally because I had struggled often with self-presentation especially with behavioural interviews.
With Kathy's presentation on "Presenting Yourself", we covered:
- The importance of confidence
- Separation of "Personal" and "Professional" values
- Breathwork - how and its importance
- Jaw Movement
- Personal Takeaway: Orbiting
Importance of Confidence
The definition of self-confidence is a state of being clear-headed that your chosen course of action is correct. For us Northcoders Graduates going into our first position as Junior Software Engineers, this means having complete conviction in our own values and the direction that we want to take ourselves.
Separation of "Personal" and "Professional" Values
Perhaps one of the most intriguing concepts that Kathy taught us was the introduction of "Personal" and "Profesional" values and separating them both.
Personal Values are unyielding values that you have when interacting day-to-day outside of work. For example, mine are: Respect, Honesty, Loyalty, Friendship and Love.
Whilst Professional Values are values that you expect yourself to unyieldingly adhere to in the workplace. For example, mine are:** Kindness, Trustworthiness, Challenge, Honesty, Recognition and Learning**. So this would translate to being able to work with people that I can trust my back to, and recognising each other's achievements and pushing each other to learn and achieve more!
But the most integral part of this was being told that instead of wearing our personal values into interviews, we should wear our professional values instead. This is because when we hold our personal values in an interview and feel rejected, then the ego would take a hit and come full circle in destroying our self-confidence.
As someone who as mentioned prior, struggled with this first-hand it made a world's difference. Instead of feeling that a company rejected me on a personal level based on my personal values, I can have my Professional Values "armour" tank the hit and keep moving forward, because it's for both party's interests to go separate ways if their values are the complete opposite.
Breathwork
When we become nervous we tend to make immediate gasps and exhales of air which leads to irregular breathing patterns. Therefore, Kathy had taught us the importance of regularly practicing inhalation/exhalation exercises so that it becomes natural during high-pressure situations.
Personal Takeaway: Orbiting
One of the key takeaways from Kathy's presentation was the idea that I'd call "Orbiting." This is the idea that reminds you that you are there to solve the company's problem. Everything that you say about yourself should always orbit back towards solving a company's problem. If you are able to check all of their boxes with confidence, then you're well on your way forward!
Careers Day - Preparing For Interviews w/ Darren Holland
The key points from Darren's presentation were the following:
- Understand and be able to explain what a company does in a single sentence.
- Research the company's mission, vision and values. What professional values align?
- Understand the organisation's history
- Fully understand the company's USP (Unique Selling Proposition)
- Understanding what makes you a valuable hire: Your successes and things you're proud of, the times that you stepped up as a leader or team member, as well as learning from failures.
A core point that Darren and the Careers Team have emphasised throughout was the importance of not just "assimilating" and pretending a company's values as your own, but really having matching values, and to communicate your entire thought process - and then whether or not your values, communication style and personality match up is nothing you can control!
Previous Technical Recruiter Linkedin Tips w/ Michael Whittam
On Thursday, fellow cohort member Michael Whittam who had previously worked as a technical recruiter shared a few useful tips for users that have never used LinkedIn before.
He had shared with us that in LinkedIn, you are able to refine your "Job Alerts" to only show certain jobs with specific keywords, and to filter for jobs that are posted most recently.
For example in the LinkedIn job alerts, you can have the following settings:
("junior" OR "graduate") AND ("software engineer" OR "software developer" OR "back end" OR "front end" OR "javascript" OR "react") NOT ("mid level" OR "senior level" OR "lead")
By refining your criteria, you will be able to have access to daily notifications for the latest jobs without receiving the "mid-level/senior-level" positions that aren't useful to us Junior-level developers!
Introduction to the Project Phase
Now for perhaps what you've come for, the actual introduction to the project phase! The Project Phase at Northcoders spans over 3-weeks and is broken down into the following:
- Week 1 - Careers Day, Introduction to Projects, Software Development Lifecycle, Communications Workshop and Project Pitches
- Week 2 - Building the project with Agile Methodologies (Scrum, Kanban, TDD, Pair Programming)
- Week 3 - Presentation Week
This week we first focused on the "Software Development Lifecycle" which are the steps that you need to take when building software. Although there are extensive resources available online and so I will just provide a brief bullet-point list:
- Feasability - How feasible is the idea in terms of: time, resources-cost, operational cost?
- Requirement Analysis - What exactly is needed to build the MVP?
- Design - How exactly are you going to break down the project into smaller parts? (E.g. Components tree)
- Coding - The actual process of coding the project with best industry practices.
- Testing - Writing appropriate unit tests for self-documentation of working production code.
- Implementation - Putting the actual project plan into action
- Maintenance - How is the project going to be maintained? (We do not need to worry about this at this stage!)
After understanding this approach you are split into groups of 4-6 people (Including yourself) and come together to develop 3 projects that you would be pitching on a Thursday Afternoon in front of your seminar group.
During the actual presentation in front of your seminar group (Not to be confused with the cohort group which is the entire cohort for the month, e.g. August/October Cohorts) in the order of the group numbers. Each group will present their first project idea and then swap to the next group. Each rotating with the mentors' feedback to ensure that each team has enough time dedicated to receiving useful feedback to improve upon.
Project Phase - Concept of Spiking
Spiking refers to a term in Software Development where you research the feasability and actual usefulness of technologies that you may have not used before for your project(s). During our time at Northcoders, we have learnt: JavaScript, React, Express and PostgreSQL as our tech-stack. Therefore, we are encouraged to explore new technologies, and so the "spiking" of technologies to check their viability is important.
Although throughout this week the concept of "Spiking" was vague - myself and the group I am working with understood that the scale of spiking is more on a spectrum that included thinking about:
- How easy/difficult is it for installation and ease of use across the entire team? Will we spend more time configuring individual setups rather than actually writing production code?
- Will this piece of technology be too difficlt to learn as a collective group for the 1-week timeframe? - The worse thing that you can do is have a single expert in an entirely new language like Go-lang and burden one member with it all.
- Is this challenging us? - On the opposite spectrum of being too difficult, are you really challenging yourselves and learning something new?
Our group admittedly had a single idea that we had thought was the "Golden Egg", but after receiving feedback from the mentors on our pitches, had come to a single idea that has had its tech-stack refined and user stories drilled down properly - the only thing now is to start writing code!
Project Phase - Agile Standups (Meetings)
This last section on the project phase besides spiking, planning as a team your projects (Which is unique to each team hence I did not write a separate topic on this), are the "Agile Standup Meetings." This is simply a meeting that is held every morning (or whenever is most convenient for your team) that aims to answers the three main questions of:
1) What did you do yesterday?
2) What are you going to do today?
3) Are there any blockers preventing you from progressing with your work today?
Just answering these three questions will allow the team to come together and work on removing the blockers so that everyone can start working right away.
Here are a few best practices for an effective Agile Scrum Meeting on the daily:
- Make sure that only one person is speaking at a time, and that you're only answering the three main questions.
- Make sure that you're swapping which person leads the scrum meetings every morning.
- Make sure that you don't have any distractions.
- Make sure that you are present in the moment.
Thoughts Going Forward
Honestly, I came into the first project phase week feeling overwhelmed because of the sheer amount of planning and actual honing of multiple project plans. Whether this was the tech-stack or creating user stories to deciding on features. But, I'm really glad that myself and my group have finalised the tech stack, decided on a solid idea and are ready to get the ball rolling!
For now I'll be brushing up on the tech stack we'll be using next week and hopefully catching up on some missed sleep!!!
As always, if you have made it this far thank you for the continued support and I hope to see you all again this time next week when the coding of our final project should be finished!
Socials
Feel free to give me a follow on any of my socials down below!
Top comments (0)