Yes that does sound like some bizarre conceptual statement. But it’s the best possible approach to solving complex coding problems, prototyping or building projects. This has become my coding philosophy from years of building projects.
Think first approach. Start with some paper 🙂
Also best suited to work in a calm space so you can focus on the work with less distractions.
You will waste way less time. Breaking down an issue into smaller tasks. Then combine them into the final product.
These should be number one best practices with software design.
Understanding the Problem: Initially, you’ll need to spend time understanding the problem and the algorithm to the issue.
Design the Algorithm: Once you understand the problem, designing the algorithm. Involves planning the data structures, the steps of the algorithm, and any edge cases to consider.
Coding the Solution: Implementing the algorithm in code, depending on the complexity of the algorithm and the language you’re using. Simpler solutions will take less time, while more complex algorithms might take longer.
Testing and Debugging: After coding, you’ll need to test your solution and debug any issues. I usually write multiple iterations of the code before choosing the best route.
I always look at the issue in detail first then decide on the best possible practice which design pattern or structure (even technology) is more suited if needed (depends on the context of the task).
Recently I was asked to do a live coding challenge (on the spot) in an interview. I wasn’t told upfront so I was caught off guard and made me feel very uneasy..
To be fair I do understand why they ask people to do these challenges but at the same time they are by no means real world environment tests and work ethics and the ability for someone to find a solution. So I find this really unfortunate as I really wanted to work with this company.
Implementing design patterns and practices aren’t always feasible with tight budgets & deadlines on smaller projects. So unit testing isn’t even a choice in most instances.
More about Design Patterns.
More about SOLID principles.
Here’s a code “challenge” from a recent interview, afterwards I looked this up and found out this is a LeetCode test so thats pretty slack on their part TBA. Its crazy to think they test peoples knowledge on LeetCode tests in 2023… Loads of highly skilled developers think these tests are by no means Real World tests, it’s pretty alarming and to be frank I may have stumbled upon the most toxic company yet. They expected someone to write this in 5 minutes too + this was over video chat and they didn’t explain what they wanted in detail (no written instructions). / rant over
// This code is written following the SOLID (OCP) principles. Open for extension but closed for modification.
See the Pen SOLID OCP IntervalMerger (cleaner) by Kurt Grüng (@kurtgrung) on CodePen.
Code:
// In the context of merging the intervals Array, using the SOLID (OCP) principles by creating an IntervalMerger class that follows the (OCP) rules that suggests that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
class IntervalMerger {
merge(intervals) {
if (intervals.length <= 1) return intervals;
const mergedIntervals = [];
intervals.sort((a, b) => a[0] - b[0]);
intervals.forEach(function (currentInterval, i) {
const previousInterval = //Conditional (ternary) operator
i > 0 ? mergedIntervals[mergedIntervals.length - 1] : 0;
if (currentInterval[0] <= previousInterval[1]) {
previousInterval[1] = Math.max(previousInterval[1], currentInterval[1]);
} else {
mergedIntervals.push(currentInterval);
}
});
return mergedIntervals;
}
}
const intervals = [[1, 3],[2, 6],[8, 10],[15, 18]];
const intervalMerger = new IntervalMerger();
const updatedIntervals = intervalMerger.merge(intervals);
// output
console.log(updatedIntervals);
console.log(`Updated Intervals: ${JSON.stringify(updatedIntervals)}`);
document.getElementById("output").innerHTML = `Updated Intervals: ${JSON.stringify(updatedIntervals)}`;