I passed every coding challenge at Flatiron School on my first try. Here’s how.
I recently finished studying Software Engineering/Web Development at Flatiron School. For those of you not familiar with the program, it is an intense 15 week coding boot camp. Throughout the time of a student studying the immersive web development program, they will have four coding challenges. Each of these challenges is a 60 to 90 minute evaluation during which a student will be given partial code and will need to complete the code in order to achieve a set of deliverables.
1. Read the read me
These are four words you will hear a lot throughout the program. There is a reason why you hear them so often; because, and this cannot be stressed enough, you need to read a read me, especially during a coding challenge. Do not merely scan the read me, you must read it thoroughly.
Each coding challenge will have a read me, a document which will contain a description of what the test is looking for, what deliverables are expected of you, and almost anything else you may need to know for the challenge. It also sometimes has a gif showing a completed version of the program you will be building.
2. Build your own projects
There are two main ways to practice for coding challenges. The first is doing old labs and practice labs. This is a good way to practice skills that you will need, find some new ways of solving problems, and get insight into what might be asked of you during the coding challenge.
Although it is definitely important and helpful to do and redo labs, one of the best ways I have found to prepare for a coding test is to build out your own projects from scratch. This allows you to ensure you fully understand all parts of creating what you will see in the coding challenge, not just the things you will be tested on.
In my experience, I found that making my own project without a predetermined set of deliverables, and therefore setting my own deliverables, encouraged me to take on a greater number and variety of deliverables than I would be assigned in a lab. This would allow me to be more creative with my self determined set of deliverables, and thereby prepare for a whole range of questions I could potentially be asked and prepare for edge cases and problems I would probably not be asked but should still know how to answer. Creating my own projects not only prepared me better for coding challenges but also helped me learn, practice, and become a better developer.
3. Show your thought process
The best way to show your thought process while writing code is by using comments. Not only can comments be used to help you organize your code and keep track of the purpose for each section of your it, comments can also be used to explain why you wrote your code the way you did. They can show how the decisions you made will help you build what you are trying to create. And insightful comments or even a well placed byebug, or console.log demonstrates to those evaluating you that you have a clear process, which in itself is important. It not only helps them to understand your process but can be a good way to refresh yourself about your coding process when you discuss your work with an instructor.
4. Ask questions
Asking questions is by no means limited to preparing for a coding challenge but it certainly is a useful part of preparing for one. Before each challenge there is a review during which there are opportunities to ask questions. If you are unsure of how to do something or struggled with something while practicing and reviewing, this is the perfect time to get clarity and ask questions about material.
By the time you have your review for the challenge, you should have already spent time reviewing and practicing. From your own practice, you should already have an idea of what to expect on the challenge itself. If you want to know if a certain deliverable, methodology, or relationship between data will appear on the coding challenge, it is perfectly fine to ask. Know that it is likely you will receive an answer of “I can’t tell you that”. However, sometimes the instructors are willing to give you a definite answer and when that happens, it can be enormously helpful in both preparing for and in taking the coding challenge.
In addition, do not be afraid to ask questions during the coding challenge itself. Of course, no one will ever hand you the answer to something but your instructors want to see you succeed and want to help you to do so. Sometimes talking out your problem with them or getting a tiny nudge in the right direction can be a huge help in solving a problem.
5. The coding challenge does not end when your time to code runs out.
When your time is up, you submit your work. Your instructors then review your code and will speak with you about it later the same day. During your review with an instructor, you will discuss your code together. If you realize you made a mistake, if you feel you need to explain something you did, or if you ran out of time and want to explain what you would have done if you had had more time, now is your chance to do so. Even though I passed each coding challenge on the first try, this does not mean I wrote perfect code, or even complete code.
When I took the third challenge, I ran out of time. In the last few minutes, I panicked and threw as much code as I could into my file. I started writing a comment about how I would proceed if I had more time and only got a sentence and a half into this explanation before I had to stop working. I knew that the work I had submitted was incomplete and that the jumbled code I had thrown in the last few minutes was filled with errors.
After the code challenge, we were supposed to have lunch. Instead of eating, I kept working on my code as if time had not run out. I continued working until I met all of the deliverables that were asked of us. When I was done, I need a list of every mistake I had made and what I had done to fix it.
When my evaluation started, I showed my instructor the working code and the list I had made. So, after that, he saw my changes, saw that I knew what I was doing, and passed me, right? Actually, no.
He told me to put my computer and my list away and then we dissected the original code which I had submitted. Again, I picked up where I had left off when I ran out of time and proceeded to build out the rest of the deliverables. Although the work I had done between the challenge and evaluation did not in itself secure a passing grade for my code challenge, it allowed me to work through my evaluation quickly, efficiently, correctly, and confidently, ultimately ensuring I did pass.
These are just some tips to help you approach and prepare for a code challenge. Although each of these practices was an important and helpful part for me in preparing for coding challenges, my last and most important piece of advice is to practice. I was not the smartest person in my cohort and I was definitely not the most experienced. However, I spent up to 14 hours a day and seven days a week working on code and ensuring that I filled any gap in my knowledge. Is this more work and time than is necessary to pass the Flatiron program? Probably. However, I have found that in trying to learn and understand programming, there has been nothing better than practice and preparation.