How do you prepare your code for programming assessments?

Tips for the day of: 1. Make sure you get enough sleep 2. Pray when you get up 3. Don't do any work so your brain is relaxed. You should have been ready by now. Last minute cramming is useless. 4. However, you can quickly review a few things that you might need to brush on and are not too technical. During my interviews with HFTs, I would just quickly check if i still remember the new features in C++17 compared to its predecessor. 5. Look at memes until the interview starts. Your brain gotta be super relaxed. It will put a smile on your face and your positive attitude will show on the interview. 6. Give a prayer of thanksgiving after the interview. 7. Study the questions you got because they might appear on your next interview (true story).

Coding assessments aren’t as indicative of ability as they might seem. Just because someone can follow directions to put something together might indicate good practice like variable naming, type choices, algorithm/logic setups - but the problem is that so many of these can be taught. “Stump the dev” coding challenges do nothing to indicate big-picture vision, interpersonal communication, and the evaluation of whether your candidate can raise the right questions. Sure, here are directions - but WHY do this? What purpose does it serve? How does this solve our bigger problem? To me that’s far more important than knowing how to fizzbuzz or rotate a matrix.

1. Get your requirements clarified before starting to code. 2. Write modular code for easy maintenance. Use functions if same thing needs to be repeated again and again. 3. Also if a portion of code is taking more than 5 lines, make it a function. 4. Making functions helps in code modification if requirements change in future or if you have missed considering any case during requirements gathering phase. 5. Keep the variable and function names self explanatory of what they are supposed to hold or the task they are supposed to do.

Well, there's multiple steps to it. First off, I wake up at 4am and meditate wearing headphones to Pantera songs. It calms me down. I then jump right in the Pacific Ocean wearing only a pair of vine leaves for protection. I need breakfast so while I'm there, I choke and kill shark with my bare hands while underwater. I can easily find sharks because I can smell their blood. I eat it raw, because it's healthier. Now, I'm fully awake, so I go back home on foot, which is about 2500 miles away. Takes me about 15 minutes tops on a bad day. I don't shower at all. I actually haven't showered since 2004, and let's not forget that all of 2012 I was in the military. I sit down at my PC, and I realise the interview is not that day.

I'd focus on mastering fundamental programming concepts, practice regularly on coding platforms, study data structures and algorithms, participate in online coding communities, simulate interview conditions through mock interviews, optimize code for efficiency and readability, stay updated with industry trends, manage time effectively, seek guidance when needed, and approach assessments with confidence, always aiming for continuous improvement.

When I interview candidates, I give them a choice to choose any programming language, or pseudo-code, or even steps written in plain English as algorithm to answer the questions. My focus is to test the capability to understand the problem and formulate a solution that can be fed to the computer as instructions in any language. This is the most basic skill of a programmer and it often goes untested when there is too much focus on technology specific evaluation. If there is a choice, it is best to choose the tool that helps you explain the solution in a simple and organized manner. Clear thought process translates to clean solutions, and that is a prerequisite for explaining the solution using any tool.

When I prepare code for programming assessments, I take it step by step. I make sure I understand the problem really well before I start coding. It's like having a roadmap in my mind. Then, I write the code neatly, like explaining a story, so anyone can follow it. After that, I test it with different situations to make sure it works right. Time management is key, so I set aside enough time for each part of the process. Finally, I look over everything one last time before I hand it in. It's all about being thorough and organized, just like in any task.

I try to avoid companies that require them. I have tried it as part of my own hiring practices and often times the code submitted is of little value versus the conversation. If through the discourse one cannot decide if the candidate is valid then perhaps the hiring practices as a whole should be reevaluated.

In my perspective, each line of the code should clearly explaing what is being executed. This will add clarity to debug and as well to expand the code further to make any other improvements

It's great to leverage your solid knowledge and principles when choosing your programming language and tools. However, the decision can be influenced by the time available for the project. Sometimes, embracing experimentation and pushing beyond your existing expertise can lead to personal growth, not only in code but in your overall mindset. It's about finding the right balance between comfort and the opportunity for self-improvement.

Use a consistent coding style. This will make your code easier to read and understand, both for you and for the reviewer. There are many different coding styles, so choose one that you are familiar with and that you think is clear and concise.

Most programming languages and IDE's can help in formatting code. IDE's are usually more lenient and allow the same construct to be written in many different forms. Code formatters tend to be more strict and result in more consistent code. As humans it becomes impossible and tedious to take all code formatting rules into account when writing code. At that moment you should be focussed on the logic and clear architecture. When reading code, the consistency becomes key as it avoids unnecessary distraction. Disclaimer: I am the maintainer of the open source code formatter Ktlint which formats Kotlin code.

Programming languages may contain built-in shortcuts to common problems such as working with arrays or traversing a file structure. Unless otherwise noted, it’s important to use these features to your advantage in building your solution.

Tools are essential for maintaining coding style and conventions. I use VS code as editing tool and eslint as formatting libraries for ReactJS projects

Professional coding style and conventions can be overwhelming to novice coders, but they can't be entirely neglected. I use a reduced set of "neatness" standards to demonstrate how using style can make code more readable for the person who might have to maintain the code somewhere down the line. To make it real-world, consider having students extend an early semester submission and see if they can remember what they were doing in the code. This sort of authentic experience, coupled with foreshadowing that different companies will have different formatting expectations tends to go a long way. The meme about indentation styles where one person uses spaces, another tabs, and yet another semi colons drives the readability point home very well!

Adhering to standards not only enhances code readability but also demonstrates professionalism and attention to detail. Established conventions serve as a common language, enabling other developers or evaluators to understand one's code with ease. Additionally, maintaining a consistent coding style reduces the cognitive load for anyone reviewing the code, as patterns become predictable and familiar. While it might be tempting to bypass these conventions under time constraints, it's essential to recognize that well-structured code is more maintainable, scalable, and less prone to errors. Thus, prioritizing style and conventions signals a deep understanding of the craft and a commitment to best practices.

Consistency is the key. Of course, when you use a language, it's a good idea to follow its standard, so follow the best practices of that language and be consistent. Let's say I prefer to open and close brackets in PHP on a new line so it is more visually aligned, so I do it everywhere where I am using the language. It is much easier now since every IDE can help you format your code to the language standards.

We should strive to write readable code that does not need to explain what it does and how. But we should definitely document the why. Not only does this force write good code, but the how usually changes more often than the why, which can easily lead to outdated comments.

Placement of comments is key for readability and maintainability. It is suggested that if comment is for a code unit (e.g. function definition, purpose, etc.) should be put before function but if there are some logical decisions have been made in code those reasons should be an inline comment. Although try to keep comments as minimum possible and improve code readability. Programming language is universal and would express better than English (or other comment language) many times.

The cleaner the code, the less documentation it needs. The focus must be to write self-explanatory, readable code. For example, it is often helpful to have each function do strictly one job, and the name of the function should explain what it does. This keeps the size of the functions small and they are overall easily maintainable. A function doing 10 different things will need to be updated if there is a change to be done against even one of those ten. Such functions need more documentation to explain what is going on. And the frequent updates to the code quickly make the documentation obsolete unless meticulous effort is put into maintaining it.

Code is generally part of a module. So you document (clearly and concisely of course) what the module does and its pre and post conditions. Implementation code, however, is expected to be self-explanatory in terms of how it does to deliver the correct outcome of the module and satisfy its pre and post conditions, nothing less, and ideally, nothing more either.

Document the public members of your code. Avoid commenting the implementation unless a specific logic must be applied. It is usually better to split the code and to give explicit naming to small methods/functions than to comment the code: comments can become outdated while small functions/methods are easy to maintain.

While I'll agree that we shouldn't be explaining what the functions we've chosen do, I do think it's important for maintainability to explain what the parameters are, the assumptions around them, the different output cases, and any exceptional behaviour that can be anticipated. Done right this sort of header comment can help write the test cases and generate support documentation (JavaDoc, etc) Other decisions in the code that are business decisions or based on some external factor beyond the simple coder's choice (if vs switch? who cares) should be explained. As others noted, adopting good style around useful variable names, etc, is important to reduce excessive documentation.

Comments have a dual nature, sometimes they are useful, sometimes they insert unnecessary lines and make the code troublesome for the eye when used improperly. It's essential to assert your skills in language and explanation before trying to explain things you can't properly understand yourself. So clean and concise code, with proper documentation and comments, is something that should follow every developer in their journey. Who knows, your code may surpass you over time and teach your grand-grandchildren coding through an AI that you trained one day. :)

I do not take an extreme side on this. I do think code should strive to be readable to the point where it minimizes the need for comments/docs. Comments actually require maintenance and can become false as the code changes, and so over-commented code can increase maintenance cost or technical debt. However, sometimes there is useful context that is not expressed by the code. Code communicates what will be executed and offers naming for data and processes, but it is limited to these things, so the idea that no well written code could ever benefit from comments or docs is too extreme a position. Libraries benefit greatly from tools such as JSDoc that provide developers with quick references and context otherwise not made obvious by code.

As per my view, your function, variable names should tell the purpose of the code. Especially in startups, you won't be have much time to write comments, you can't write comments to each block. Best way is to maintain proper function names and variable names, any way your comments for another developer only not for general users.

A well written and easy to follow code is better, documentation tends to become outdated as code gets updated but comments do not

I'm not much of a fan of coding testing, especially given the nature of my work. Sometimes, it can be bothersome to add on top of other tasks, and it's time-consuming, which can lead to fatigue. So, when I mention time-consuming, it means that in cases where good planning, respectful deadlines, and well-organized teams are in place, implementing software testing can be considered a "luxury." However, it should not be seen as an industry standard that must be forcefully implemented everywhere.

A competent programmer must have the confidence that what s/he has coded works as expected. But we all make mistakes regardless of how confident we might be about what we did. So testing is to safeguard our confidence against individual tendencies of making mistakes like typos, misplace a statement or two, "off by one" loops, or missed "corner cases". If someone needs a debugger to tell whether the code logic is correct, s/he might well be an incompetent coder...

The best is test driven development: write your code expectations first (the tests), then implement your code. By doing that incrementally (one test, one small piece of code at a time), the amount of code is reduced and the probability to write bugs too.

Every line of code written holds the potential for errors, be they syntactical, logical, or run-time. A robust testing regimen, employing unit tests, integration tests, and more, acts as a safety net, catching discrepancies before they escalate. Debugging, on the other hand, is the art of detective work in the coding realm. It's about tracing the root of an issue, understanding its cause, and implementing the most appropriate fix. Beyond just rectifying errors, this process deepens a developer's comprehension of the code and the system's intricacies. In essence, by emphasizing testing and debugging, one ensures that the code is not only functional but also reliable, efficient, and resilient against unexpected scenarios.

Testing in the sense of your traditional unit test, in my experience holds little to no value for the most part at least in a large corporate setting. Integration and system tests do tend to flesh out a lot of issues though.

Testing does not mean you are a bad programmer. Rather, writing test cases shows that your are aware of the common communication challenges of working on a team, and the test cases are a protective layer for the functional requirements. Often, it’s tests like these that lead to less downtime and on call actions for teams.

Students often skip testing, and then they feel shocked when their grade isn't where they thought it should be. Adopting good time management skills that leaves room for testing and debugging is critical to success in computer science courses. If you can't debug it, you don't understand it. If you don't understand it, it's going to be hard to use it in novel situations when you leave the classroom. The solutions to all the world's software problems are not on StackOverflow! As AI assisted code becomes a norm in our industry, validation that the code behaves as desired is going to become a critical part of making these tools accepted parts of eliminating some code drudgery!

What I do when doing a tech assessment is to ask if it’s possible to add unit tests (which I know is a good sign in code assessments). For example, if you need to solve an algorithm problem, like “create a function that receives a string and return true or false if the string is a palindrome”, you could do the next (in JS): test(“return true when receives ‘ada’, () => { expect(getIsPalindrome(‘ada’)).toBe(true); }); And for bad paths: test(“return false when receives ‘oda’, () => { expect(getIsPalindrome(‘oda’)).toBe(false); }); Even is not required for your assessment or competition, it will help you a lot validating that your solution does what is required, and is a clear sign of your professional experience as engineer.

You should always test your code before pushing it for others to use. Why? well, because testing makes sure that it works accordingly to requirements. Especially, test for those edge cases. I would say testing is not the process to fix errors, it is to find them if they are there. To fix them you use debugging Debugging is a process of locating the location of the problem using any means you have in your possession. Debugging lets you find the location and shows you what the program is doing, so you can fix the the problem

Refactoring is the process of moving a common block of code to its own location (function) and then calling it from all the places that have that logic. My rule of thumb is if the code appears more than once, refactor it. Refactoring has too many benefits: cleaner code, more readable code, easier to update code, better optimized code....

Donald Knuth wrote "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." Getting the software working is mission 1. Revisiting it and improving it so that it works better is mission 2. First to market business strategies rely on the assumption that the customer will accept flawed software in order to have early adoption, but they also rely on iterative improvements!

Refactoring involves restructuring code without changing its external behavior, aiming for more maintainable, readable, and scalable solutions. It's like reorganizing a bookshelf to make it both aesthetically and easier to locate books. Optimization, meanwhile, focuses on enhancing performance. Whether it's improving algorithmic complexity, reducing memory consumption, or shortening response times, optimization ensures that code runs faster and consumes fewer resources. Both practices demonstrate a developer's commitment to quality and longevity. In a constantly evolving tech landscape, taking the time to refactor and optimize not only bolsters the current codebase but also paves the way for smoother future adaptations and integrations.

There is no optimized code at first drop. It's iterative process to bring it to next level. Swing moves between space and cycles - set the right target and iterate. It's also not a bad idea to keep multiple versions for same function for customization.

I could see lot of Devs make this mistake of premature optimization, even during their Assessment. Due to this, they were not able to complete the set of features requested, so make it work by building with the PoC first aprroach then Optimize you code, introduce Design patterns and make your code more readable.and extensible

Refactoring and optimization tools and techniques can not compensate for an initial poor design and implementation. However if we are talking about a small piece of code for a programming assessment, and not a production software, a second look at the code and any refactoring is good.

Do not expect refactoring/optimizing techniques to be able to rescue a poorly designed or a fundamentally flawed program. These techniques, if used properly, can make our code better to be maintained and evolved, but almost never make it fundamentally better (without essentially a redesign of the code) ....

We should strive for getting the best code design we can right off the bat. However, the best design is both subjective and changes over time. When need for change is ignored too long, developers may protest that they must have a refactoring hiatus. We should strive for an initial design that is flexible but not over-complicated, specifically leaving room for increases of complexity. Principles like SOLID can help with this. Refactoring can then be a natural and continuous part of development. Think like CI/CD, less "waterfall" code improvements. I think that anyone could benefit from reading Refactoring by Martin Fowler, which defines an approach to writing code like this, with testing and source control practices in necessary harmony.

Once you’ve setup your test cases, you can essentially think of your method(s) or function(s) as a black box. You are free to change anything inside so long as your well-written tests continue to pass. Using a technique called Red Green Refactor, you are able to quickly test and reimplement solutions to achieve better performance or other metrics you may be aiming for.

If you write well organized code, comment it (a habit), short explain your logic in comments then most of the time. you don't need to prepare your code for submission. Of course, each company is different, you might need to do an extra thing or two, but mentioned above is just the common sense

I do not prepare my code for an assessment. I do use tools which identify common issues. And I do use an auto-formatting template. But that is part of my normalbdevelopment process. If people want to assess my code, they are free to do so at any time.

Write code that you would like to read, even if it's you in a few months. Naming, tests as examples, etc. Doctest, cargo, etc

Coding a real project and coding a code assignment are two different things I believe coding assignments are a broken way to test the person. I believe that interview should know what questions to ask in order to determine if a candidate knows how to code. We all have our coding styles and thinking hats so the most important thing is to solve the issue and build the proper algorithm. If you have proper algorithms the coding will follow.

I just say "no" for coding assignments / live coding tests 99% of the time, unless the project and the company/people are super interesting / very well paying. In my XP, highest paying / most reputable jobs never involved this kind of stuff anyway. A live coding test or assigment given above junior level is usually a huge red flag, as it kinda means that the company doesn't respect your time.

With today's dysfunctional interview processes, there's a good chance your submission won't even be looked at. Try not to take it too seriously!

* Measure performance quality of code * A senior engineer should be well versed with Quality Analysis of the performance of code - rather than just writing it. If code is for resource critical platform, then gather profile info (i.e. MIPS and heap) of the key algo functions, which are being called repetitively. Optimisation should only be applied for re-entrant code, otherwise it is wastage of time to optimize non-critical path.

Codility assessments, for example, showcase one’s proficiency in solving puzzles rather than accurately reflecting coding skills. Requirements are written in riddle format adding to the overall uselessness. They can be fun if you’re just practicing but, 45mins - 1hr to do half days work in most cases… mostly consisting of ironing out what’s expected, can be frustrating.

Have you been looking at points 1 to 6 above? If you ever wrote code before, have you been heeding those suggestions? No? Tststs ... Yes? Well, then just code as you always do. You are in great shape. Starting from understanding the challenge, move on to a clear idea of what the solution must do and write it down, explaining what you are doing (and why) in your comments - as always. (And if you didn't always write your programs that way, spend some time afterwards promising yourself that you will now always work this way.)

Seems like this article ruffled some feathers.. with many answers relating to coding interviews rather than assignments. I don't think anyone who needs to submit one in their interview process would even look for advice like that. If they have and want to do it - they should, to the best of their craft and knowledge and there is not much more to be said IMO.