×
We’re excited to have Zach DeRossette join the Rithm team as our Career Coach! You can find him meeting with and supporting our students and alum throughout their job search. Here we learn a little bit more about Zach, his role on the team and his advice to job seekers (including spend less time applying online!)
At Rithm, we believe that one of the best ways to prepare students for jobs as web developers is by giving them opportunities to work on real-world projects. Working on personal projects can be fun, but working in a team or on an existing code base gives students insights into the day-to-day challenges of a developer that they might not otherwise learn. Our 10th cohort recently completed their company projects, so we spoke with Lena to get their perspective on the experience.
When you're first learning how to code, error messages can be intimidating. Because of this, beginners sometimes ignore error messages entirely. Instead, they will favor more of a "guess-and-check" approach to fixing bugs. While we don't encourage this approach at Rithm, we recognize that in the context of solving small, isolated problems, it can be successful. But when it comes to working on larger applications, professional engineers need a more sophisticated set of tools to fix problems.
Fortunately, one of the most successful strategies for fixing errors is also one of the oldest: applying the scientific method. In this post, I'd like to review the scientific method, and highlight how you can use it to solve programming problems more quickly.
Code reviews can be a common practice for many developers: another engineer, often more experienced with the language, library, or code base being used, meets with the author-developer to read through their work, ask questions, and provide suggestions for improvement.
This process can be a positive experiment for many, but often, it can be challenging to be on the receiving end of a review. These can descend into demands for needless uniformity of style ("no! it's super-important to align your code just so") or they can create uncomfortable or harmful power dynamics between peers about whose style or ideas are "better." At their very worst, code reviews can merely provide cover for biased viewpoints or microaggressions directed toward developers who may have less power in organizations.
While we recognize that not all parts of this practice are always helpful, we do encourage a lot of code reviews for our students here at Rithm. We think that, especially for newer developers in a class, these can provide useful feedback and lessons that can be difficult to get from lectures or books, and can also be hard to notice just from reading other code.
Despite its best intentions, JavaScript is not the most beginner friendly language. After working with thousands of beginners, here are a few common mistakes we see with applicants and students.
A little while back, we wrote a post on the top four javascript mistakes beginners make. In this post, we'll be adding a few more we've seen to help you better prepare when learning the basics!
Let’s imagine we have the following object,
var instructorData = { firstName: "Elie", employer: "Rithm School", favoriteNumber: 42, isHilarious: false };
When accessing a key in an object, there are two possible ways to go about it.
dot notation
bracket notation
Knowing when to use which one is essential, so here is a good rule of thumb to follow.If you know with 100% certainty what the key is - always use dot. If you are not 100% sure what the key will be, you must use bracket.
Before joining us for Rithm’s 6th cohort, Miranda worked as an executive assistant and office manager in the tech industry, after getting her BA in Psychology from NYU. A San Francisco native, she also is a volleyball player and a self-identified graphic novel enthusiast. Miranda took some time to discuss her job search, her experience at Rithm, and her steadfast friendship with Whiskey the dog.
Before Kristen discovered programming, she was an elementary school teacher, and then a stay at home parent. When she’s AFK, she loves reading (If something has to do with magic or outer space, she’s probably read it or wants to read it), puzzles, games and travel. Her idea of a great party involves tabletop games, wine, and puns so cringe worthy that even your dad would groan. Kristen was able to take some time from her busy schedule to share more about her experience as a student, offer her advice for new students, and explain how the skills she learned at Rithm School will be used in her new position as a Software Engineer at Maven Technologies.
Before joining us for Rithm’s 7th cohort, Tyler Ketron got his hands dirty (and sometimes still misses it!) as a hydrogeologist at government agencies and a consulting firm. When he’s not busy at his new job as a Front End Engineer, you can find Tyler competitively weight lifting, raising chickens in his backyard, or flexing his classical musician skills with the oboe and piano. Luckily, we were able to catch some time to sit down with Tyler and discuss his journey from growing up in a small town in Tennessee to becoming a software engineer.
In May of 2018, Blind (an anonymous community work app) released a survey that revealed that close to 60 percent of employees surveyed considered themselves burned out. With over 11,000 respondents from the biggest tech companies in the game, it verified what those in the trenches were already well-aware of: burnout in tech is ubiquitous.
At Rithm, we believe that one of the best ways to prepare students for jobs as web developers is by giving them opportunities to work on real-world projects. Working on personal projects can be fun, but working in a team or on an existing code base gives students insights into the day-to-day challenges of a developer that they might not otherwise learn. Our 8th cohort is nearing the end of working on these projects, so we spoke with our students Sarah Kaplan and Zac Bennet to get their perspective on the experience.