What is REST? That is one of my favorite questions when conducting a technical interview. You can learn so much about one’s practical experience with web services and applications by simply chatting casually about REST. I’ve heard so many definitions over the years. Even people who have built many web services do not always agree on what is and isn’t REST.
When it comes to loading time of your web application speed is always a major aspect. A simple web site that loads very fast is the best user experience. Speed is always in style. If you wonder whether your web site is fast or slow, you can always ask Google for that. Simply go to the Google PageSpeed Insights, enter your website URL and they will analyze it for you.
It requires a good amount of hard work to keep up your internal design documents up-to-date as your codebase evolves. It is even harder to enforce that practice within a large team. Sometimes people forget to update a wiki page after making a change to the code. Sometimes they do not update it on purpose as they believe no one would ever read those documents. And sometimes they are just being lazy.
In my early years as a software developer the moment I have learned something new I was eager to use it all around my projects. Right about that time the concept of inheritance hit me stronger than before and I was like “That’s cool! Let’s use it everywhere :tada:”.
Statically vs dynamically typed programming languages. This controversial topic is old as the world but still pops up on almost every developer gathering. Everyone has a preference and everyone is zealously defending their side. Let me tell you how I see things in this controversial matter.
I can bet a good amount of money that at least once every week you have to write this tiny little method that is used across several classes but does not fit either one of them. The head first thought is to put that code into that big junky Utils class like a homeless child.
Many teachings preach that it is a good practice to comment your code so that your fellow programmers will know what the heck that code does or why it was written in such a way. There are many reasons why developers write code comments. A few of them sound legit. But most of them don’t.
There are many articles, blogs, guides, books, poems and urban legends on how to keep your Rails controllers clean and simple. At job interviews that very question is being asked almost every time. Because of all that fuss around thin controllers even junior programmers without much of a practical Rails experience know THE answer.