Firehose Project Week 8
The 4rth app that was developed using TDD - Grammable. It is quite simple (the app, not the process), yet it is much more professional (in the back-end) than other apps that I have built in a sense that it employs industry best practices (as any app should, as it turns out).
I have also mentioned a couple of weeks ago that I have quite a lot of algorithm tasks to solve and I really felt that it was the area that I needed to work on as I kind of neglected it a bit.
Knowing Algorithms is Bloody Important
I did not solve as many of them as I used to in the first weeks of the bootcamp, so this week it was my main focus to fix that. One of the things that Firehose Project founders Ken and Marco stress is the knowledge of Data Structures and Algorithms, so the course is packed with pretty challenging tasks. Each is exposing you to a new DS and a new way of thinking about the problem. For instance, I had 2 algorithms to solve that involved Linked Lists and a Stack. Ruby as a language doesn’t even have these types of data built-in, but it is relatively easy to implement them manually… But hell! How hard it was to reverse a Linked List, first with the use of the Stack and then without - my mind melted probably 3 times before I got it. :)
By the way, one of the Firehosers (student) wrote an article on LLs to demystify the concept.
Their complexity was far more advanced than the ones that I used to solve on my 3rd and 4th weeks and each took several hours to solve. It was discouraging really, it felt like if I get one on a coding interview, I would just fail it.
On my mentor session, to my surprise…my solutions did quite well. That is not to say that I have solved ALL challenges with ease (actually, one wasn’t solved but I was very close to getting it right). I shared my concerns with my mentor and his response was (in my own words):
Don’t get discouraged that it takes you a long time to solve these algorithms - that are made to make you think hard and are usually above your knowledge. Having skills to solve them is important, yes, but it is ok to fail too, even on the interviews. When you are given a puzzle to solve on the interview, it is not just about solving it. It has more to do with how you think, how you deconstruct the problem and what approaches you use in your attempts solving them.
- My Mentor :)
You shouldn’t be afraid to ask your interviewer questions if they are relevant most of them will give you a hint. You can also say something along the lines “here is my code and this is how it works. I wasn’t able to solve the problem entirely and I know there is a method in insert you programming language that would make my solution work. I would have to look into the documentation to double-check it.
This was the best piece of advice I got this week.
As a follow-up, he also sent me How to Win the Coding Interview article, which pretty much confirmed everything he said to me during our session. My mentor is a pretty awesome mentor actually :)
That would be the wrap-up of this week…
As I had to do some part-time work this week, apart from algorithms and Grammable, I did not do much else. Well, ok - I read the Brave New World by Aldous Huxley, and I bloody loved it!
Happy Coding!
My Journey at Firehose Project: 61.54