DEV Community: Neal Burger

Ready Set Action

Neal Burger — Mon, 05 Sep 2022 22:02:03 +0000

Photo bySevenStorm from Pexels

You are at your computer, you are motivated and fully engaged to start working on your personal project. Now is the time to take action. - Only a few seconds later you are staring at a blank screen. You have no idea how to start your project. You start to overthink your project. You realize developing Software is hard and your brain prefers to do easy things. Before you even notice, it is way past your bedtime. - You basically spent the entire evening procrastinating instead of working on your project.

There must be a quicker way to get started and remove the obstacles that prevent you from taking action. Let's have a look at a couple of strategies that might help.

The Obstacles

Overcoming The Blank Canvas Paralysis

Artists have problems when they start to create an artwork, they take a look at a blank canvas and think:
Look at it's beauty, the infinite white, the perfection, every part of the canvas is perfect. You are a flawed human that does not know anything - how could you even create any sort of masterpiece that will justify destroying the perfection of this empty page.

Something similar happens when you open up your code editor and you stare into the blankness of the page. You can create anything. In most cases you do not yet fully understand the problem you want to solve. Your solution could make things even worse, "every line written is a potential bug". So you are paralysed to start.

What really helps is to limit your options and make a more clarify for yourself what you want to do. I want to create a drawing gives you unlimited options - however if you say I want to draw a cartoon cat at nighttime in Paris, limits your options and helps you to get started. The clearer your vision is what you want to do the easier it becomes to execute your plan.

You have to get started with your project. Starting a project always requires a lot of willpower and energy. Once the project has started it is much easier to continue working on the project as the project gains momentum.

To start any software project, just create a simple "Hello World" - Program. It is really that simple. Just by creating this simple program. You made a decision on the fundamentals of the project - which programming language, the initial tech framework etc. You then extend that project and then rewrite it to the project you want to create.

You cannot make a wrong decision. The worst thing that might happen is that there is some work is required later on. You can always rewrite and switch your tech stack later on. It does not really matter, every tech stack has its trade offs. Later when your project is successful you can reevaluate your initial decision. And if needed rewrite the entire project in a more efficient way. The important thing is that the project gets started - and remember:

It is better to make mistakes and correct them later on than not starting.

Overcoming Procrastination

Procrastination is the habit of delaying an important task, usually by focusing on less urgent, more enjoyable, and easier activities instead. MindTools

Procrastination is probably the most fancy word you for saying that you are distracted by the internet. The only way of beating Procrastination is to take action and get the hard task done. In short stop reading this article and get to the task that you are putting off. It is that simple.

Unfortunately you just continued to read this article, so lets dig a little deeper what is going on and how to develop a strategy to procrastinate less. Your brain is not convinced that the effort to complete the action will match the reward. Most commonly people procrastinate with social media, it is always unexpected and you will get some emotional response, if is positive, funny, or something that makes you angry - it is an easy task that will always reward your brain that it did the task.

How do you beat Procrastination

Every person is different, here are a couple of common strategies that can help. You can tackle Procrastination from a couple of angles: Internal Dialog, Distractions, Rewards and Commitment

Internal Dialog

Your internal dialog is going to try to persuade you to do other tasks. In the worst case even just start to become negative and steal the energy needed to complete the task. By adjusting your internal dialog to something more positive can help you complete the task.

Forgive yourself for procrastinating in the past. You should not beat yourself up because you did not yet complete the task. It does not matter - you can forgive yourself and look forward. Have a positive outlook for the future and that you are going to complete the task.
You are in control of your actions, you are actively choosing to do tasks - You feel disempowered when you constantly are telling yourself "I have to do this task". It makes you feel that the tasks you are doing are out of your control. When you rephrase it to: "I choose to do this task". You actively make yourself aware that you are choosing to do this task. You are in control and the task is not forced upon you.

Reward

Most work does not have any meaningful reward attached to it. If you can find a way to increase the reward the easier it becomes to get the task completed.

Define and give yourself a Reward for completing the task. - Your brain wants to be rewarded for doing the hard task, it will make it easier to convince yourself to get the task done when you exactly know what the reward in the end is going to be.
Do everyday the most annoying thing first. This has a built in reward. The reward of completing this task is that all other tasks that you have to complete that day will be more pleasant. In addition you do not have to dread this task the entire day.

Handle your Distractions

In reality you still really do not want to do the task. You will welcome any distraction that comes along to avoid continue work on the task. By minimizing your distractions you are just more focused on the task at hand and more likely to complete the task.

Immediately complete the task - If it is a small task just do it immediately. This just eliminates the possibility of procrastination from the beginning. In addition you do not waste any time thinking about the task and feeling bad for not yet have done this small little task.
Control your Distractions - Be more aware of what is distracting you from completing your task. Minimize as many distractions as possible.

Commit yourself to the task

When you get around to doing a task is a question of priority. If something is really important for you, you are going to take care of it. By committing yourself to a task, you will feel obliged to actually finish the work.

Internal Commitment - You make a contract with yourself that you will complete a task. Treat your Todo List as a collection of contracts that you must fulfill. They have a clear definition what needs to get done, a specific time when you will do them and when they have to be completed.
External Commitment - Basically ask someone to check up on you. This can be a major productivity booster. Peer pressure definitely works and it works especially well when you are working together to a similar goal. This is the principle behind self-help groups. Note: This also can be a terrible idea. It is much more fun to procastinate with a friend.

In short: You have to show up and focus to complete the task.

Be aware of "Productive"-Procrastination

There is a piece of advice when you are writing a book: "Do not tell anyone that you are writing a book". The reason is, while you are talking about your book, you are actually not writing your book.

The problem is that you already spent mental energy thinking about your book. Your mind marks it mentally as a completed task for the day. In reality you did not write a single page.

A similar thing happens when you say: "I cannot start the project, I have to read up on the subject first." Developers will spend hours reading books and experimenting with tutorials, watching tech talks - But actually they were avoiding the work on the actual project.

You have to make a distinction if you are reading for your own personal entertainment (i.e. procrastination), or if you are reading to take action. When you are reading to take action, you are taking notes, you are letting the ideas of the book influence your thinking and inspire you to take the next step with your project.

More Resources

Anti Procrastination Strategies

Analysis Paralysis

Engineers are trained to analyze every situation. They deeply think about every scenario and every edge case that could go wrong. This might be the greatest strength and the greatest weakness of engineers.

Instead of taking action and fix things along the way engineers sit down and start to analyze the problem. Every edge case and every scenario how the project could fail. They are so engaged to focus on the faults of the idea that they never start.
Even if the project has a 99% success rate an engineer will struggle to get started. It is impossible that the risk of failure is only 1% the analysis must be flawed.
In short, they start to overthink and over-analyze effectively stopping them from making any decision. They are stuck in Analysis Paralysis.

You have to come to the realization that every possible solution will have flaws. In reality if your solution covers 70% of cases you have a more than average solution to a problem. The remaining issues can be solved over time, or can be solved with another solution.

Making a decision, committing to any plan of action is better than doing nothing. When you are coding, you will have to rework your code eventually. The rework is always going to be simpler than getting started. No matter what you do your decision will have some sort of downsides.

Overcoming Fear of Failure

‘From failure we learn, from success not so much’. Lewis in Meet the Robinsons

The important thing is to accept failure and learn from it. You will recover. And because you have failed it is more likely you will succeed the next time.

In fact you should seek out to fail faster - because with each failure you learn something new that will improve your project and it will make your success even more likely.

More Resources

Fail Faster

Overcoming Fear of Success

Often you do not have a fear of failure, but actually a fear of success. When the project succeeds then your life will change. Frankly no matter what your situation is, you prefer the status quo. It feels familiar, controllable and why do you want to change. It is much easier to imagine this new life compared to put in the hard work to actually obtain that life.

The reality is everything is always constantly changing. By working on your project you are taking control of your life and that makes it easier to embrace the constant changes.

Developing a System to make it easier to start

Promodoro Timer

A Promodoro Timer follows a very simple concept: 25min work then 5min break
You can choose whatever time interval suits you best. It is a fixed time of work and then a fixed time of relaxation. It is a very powerful technique if done correctly.

To make the promodoro timer technique work, these prerequisites must be met:

You commit to the task
You commit to the deadlines (i.e. the task must be completed and more importantly the reward activity must end on the timer)
The task is predefined - and must be completed during this time and you do not permit interruptions
You know what activity will relax you after the task.

What happens if I do not met these prerequisites? You just found a way to procrastinate on a timer. When the prerequisites are not met suddenly the timer tracks 5min work and 25min procrastination.

5 Tasks a Day

There is a simple technique to figure out what you should focus on:

Write down the 25 Items that you need to do.
Identify the 5 most important tasks
Only focus on these 5 items before moving on to the other items on the list

Overall this technique can be useful for organizing your day to day todo list. It is very likely that you will only find the time to complete 5 tasks per day.

Note: This technique is often associated with Warren Buffet and how to achieve your life goals. He however debunked this myth. He does not use this technique and it apperantly also does not work when applied for life goals.

Create Streaks

The more often you work on your project the easier it becomes to get started. Working on your project should become part of your daily routine. One way to establish this is to create chains in your calendar.

Get a wall calendar
Put a big x on every day when you worked on your project.
After a couple of days you will have a chain. Your only job is to not break the chain.

The beauty of this technique is, that it automatically creates a visualization of your progress. At the same time it is a visual reminder that you should work on your project. It does not care about if you are motivated, how much time you spend working on the task, or if you are getting the results you expected. It only cares about that you show up and get the work done.

Important: You are allowed to break the chain. Breaking the chain does not mean that you failed. It just means that on that day other things were more important. That is ok. Just start a new chain and see how long you can make it.

Note: This technique is often referred to the "Seinfeld Strategy". Jerry Seinfeld, was asked in a Reddit AMA if the legendary story was true, however he debunked this story.

Accomplishment Journal

A similar method of visualizing your projects achievements is to have an accomplishment journal. In this journal you keep track of all the accomplishments of the day.

It is very simply to create this journal.

Set up a reminder in your calendar to write down your achievements of the day
Write down all of your accomplishements of the day. It does not matter if they are big or small.

Just by writing your accomplishments down you will recieve a confidence boost. When you have self-doubt you can flip through the pages and remember your accomplishments.
In addition the journal helps you keep you on track and visualizes your progress. In addition it motivates you to do at least one thing that you can write down in your journal.

Note: This journal helps you to communicate your achievements to your manager in a weekly/ monthly status report. It also can help when you are appling for jobs, you can then easily reference your achievements.

Consistency is Key

Every journey starts with a single step.

But to complete the journey you must take one step after another. Now I wish you good luck on working on your project.

If you like leave a link to your project in the comments.

Writing Shell Scripts in JavaScript with ZX

Neal Burger — Thu, 23 Jun 2022 00:00:00 +0000

Photo by JÉSHOOTS from Pexels

I was working in the past on a project, that was still requiring us to do manual releases. We followed a short guide consisting of Terminal commands. Only a minor adjustment was needed for each new release. We could have greatly benefited from writing a simple bash script. However I am not a sysadmin and tend to rarely write shell scripts. It would take way too much time to debug and create a working bash script. We decided copy and pasting code is just more efficient.

Luckily the developers at Google also did not want to write bash scripts. However apperantly they got the resoruces to create something even better:

zx - A tool for writing better scripts

It allows you to combine JavaScript with the Bash commands to create complex scripts. At its core its just a simpler wrapper syntax for working with NodeJS child_process.

The Release Script

Our build steps are basically:

Bump the version in package.json with the command npm version patch
Pass the new version number to the releaseCMD

The reason to do this manually was that there is no easy way to read the new version number from the package.json to store it in a variable to pass it into the releaseCMD

The ZX Script

Output Text to the console

Its always useful to output stuff to the console. You can simply use console.log("Hello") to output text on the console.

Execute Commands

As alternative if you want to execute any terminal command like echo to output text. You write it as
$\echo Hello

Read JSON

The Github Page of ZX has a list of typical commands and examples what you can do with them. One of them is to read the package version

const { version } = await   fs.readJson("./package.json");

Let's put it all together

I created a directory scripts that will contain all the future projects scripts and created the file release.mjs

/scripts/release.mjs

console.log('Running Release Script')
await $`npm version patch` // Bumps package version
const { version } = await fs.readJson('./package.json') // Reads new package version
try {
  await $`echo releaseCMD -version ${version}` //Replace with actual command
} catch (p) {
  console.log(`Error: ${p.stderr} ExitCode ${p.exitCode}`) //Logs Error to the terminal
}

Executing the Script

You either can install zx globally with the command

npm i -g zx

or you can run it with npx zx <scriptname>.

Personally as soon as I am done with the script I don't want to deal with this anymore. I want that every team member can use the script without any explanation.
Thus I added it as a script in package.json

/package.json

{
  "scripts": {
    "release": "npx zx ./scripts/release.tjs"
  }
}

Now you can run it like any other script npm run release

Conclusion

Unfortunatly I did not have a lot of time to play around with ZX. I am sure that it is capable of creating very complex scripts.

For my usecase I did not look into executing scripts as an admin, or creating cross platform scripts etc. Again I am not a sysadmin.

In the end, I think ZX is a great way of creating shell scripts without having to deal with BASH. Thus with your TypeScript/JavaScript knowledge you can quickly create scripts to automate the boring stuff.

Typescript - Myths vs Reality

Neal Burger — Sun, 12 Jun 2022 20:37:15 +0000

There is always some resistance when you introduce TypeScript to a codebase. You probably will run into a couple of misconceptions and myths surrounding TypeScript. Let’s debunk the following myths:

TypeScript Slows Down Development
JSDoc Typings are enough
TypeScript prevents all bugs
TypeScript adds clutter to the codebase and more bugs
TypeScript Compiler Errors are no real bugs

1. TypeScript slows down development

TypeScript requires some additional setup, needs to be compiled, and you have to write more code. Thus TypeScript development must be slower.

Lets take a look at the entire development process:

Initial Setup
Compiling
Writing Code
Reading Code
Changing Code

Setup

JavaScript projects usually will set up the BabelJS compiler and a packager like Webpack.

TypeScript projects are set up identically. The only difference is that you have to add an additional BabelJS Plugin to remove the TypeScript typings. In addition you use the TypeScript compiler to check types.

The effort for both is identical.

Compiling

A typical Frontend Development project will have two separate processes for development and for production. The compilation time of both processes can be quite different.

Compiling during development you will be using BabelJS for JavaScript or TypeScript, the processing time is identical. For TypeScript additional type checking will be done by your code editor in the background.

Compiling for production will add for TypeScript an additional compile step for type checking. It can be run in a separate process. It can add a small overhead. However since a production build is run by a CI/CD Pipeline it should not impact your development velocity.

The effort for TypeScript is minimally higher.

Writing Code

When writing new code developers have to start to consider types - this makes writing TypeScript ‘slower’ than writing JavaScript. This is a very good thing. It is the first minimal step to actually think about code design before you code.

For developers that are used to dynamic typing it is initially hard to take types into consideration. But with experience and familiarity you will barely notice a difference.

Reading Code

However, writing is only a small part of development. Reading code is a much larger part of development. TypeScript significantly improves readability.

Look at this example:

const initJS = (options) => {
    ...
}

const initTS = (options: { debugMode: boolean}) => {
    ...
}

With initJS you are going to have to read the entire implementation to figure out what parameters you can pass to options. Yes, I know you could use JSDoc to describe it, however as you can see with this example the developer that wrote the code did not add that comment.

With the initTS it is clear that you can set the parameter debugMode. In Addition, not only is it easier for humans to read the code, your IDE can now also provide you with significantly more accurate autocomplete. Saving you even the switch to the file when you want to call the function.

Adding types will not only improve your function signatures, it will also make it much easier to understand the implementation. In addition it prevents code smells like reusing the same variable for multiple different contexts.

Changing Code

With JavaScript if you change a function signature, you have to manually check every piece of code that is calling the function. If you miss a single adaption, you will first see it when you run that piece of code. If that piece of code is not run very often, or a different developer encounters it you will waste a lot of time on debugging to figure out what exactly happened.

With TypeScript this is done by the TypeScript compiler and it provides you an output of all the instances where the code will now run into a problem. While you are developing you will be able to fix the issues immediately.

Summary

Does TypeScript really slow down development?

Initial Setup - Identical
Compile Time - Identical
Writing Code - JavaScript minimally faster
Reading Code - TypeScript faster
Changing Code - TypeScript significantly faster

Yes, TypeScript adds a small overhead to your project, but at the same time it drastically increases your development velocity.

2. You do not need TypeScript - JSDoc static typing is enough

JSDoc allows you to define types with the @type syntax. This allows you to document your code like this:

/**
 * Simple Addition
 *
 * @param {number} a
 * @param {number} b
 * @returns number
 */
export const add = (a, b) => a + b

add('12', 2) // Argument of type 'string' is not assignable to parameter of type 'number'.

This annotation is a significant improvement compared to undocumented code. In addition code editors will now take this comment and interpret it and display warnings in your JavaScript code.

The argument is now: Well we already have basic type support why do we need the typescript compiler?

You only get warnings for files you are currently looking at, you are not aware of files that stopped working because you changed the function signature. The TypeScript compiler will throw an error for all files impacted by the change.
They are comments, developers tend to forget to update them correctly.
You are limited how to defining complex objects or how to reuse them.
You do not benefit from the existing TypeScript definitions provided by the TypeScript community.
By using JSDoc you are utilising already the TypeScript compiler. Your code editor just runs it in the background to generate the warnings. You can learn more about the feature here.

Using JSDoc is a great starting point to get your team familiar with defining types.

It does not make sense to only use a small subset of TypeScript with an overly complex syntax that some developers forget to update.

3. TypeScript prevents all bugs

No it does not. It prevents the most common type of bug in JavaScript a TypeError.

You should use testing strategy like Test Driven Development to eliminate even more bugs. Ideally you are using a combination of TypeScript and tests. By using TypeScript it makes it easier to write the tests, and you are not constantly writing tests to ensure the correct type.

AirBnB estimated that 38% of bugs can be prevented by using TypeScript. Even without any other benefits - just to reduce 38% of bugs is already a very big deal.

4. More clutter more bugs

More Lines of code more potential bugs. Yes, this partially true. With TypeScript you introduce the possibility of incorrectly defining your TypeScript types. Again, TypeScript is not a test strategy. You have to add testing.

However if we add the same functionality of TypeScript to JavaScript, you will see that TypeScript actually reduces clutter:

const addJS = (a, b) => {
  if (typeof a !== 'number') {
    throw new TypeError('a is not a number', a)
  }

  if (typeof b !== 'number') {
    throw new TypeError('b is not a number', b)
  }
  return a + b
}

Compare this to a similar code in TypeScript:

const addTS = (a: number, b: number) => {
  return a + b
}

While it may appear to be more clutter in TypeScript, most likely you are not writing any type checks in your current JavaScript code, and have many potential sources for Type Errors.

5. TypeScript Compiler Errors are no real bugs

You have a legacy codebase - the team is convinced - the code is ‘bug free’. Now you add TypeScript to this codebase and suddenly TypeScript outputs hundreds of compiler errors.

The first reaction is going to be denial, these ‘errors’ are not real bugs. There is no need to fix them.

This is true for the moment. The code is seemingly working correctly if nothing changes, the inputs are always the same, the output is going to stay the same. In practice however you are adding new features and are fixing bugs in the ‘bug free’ software. Things are changing all the time in the codebase.

You should be treating the TypeScript compile errors as bugs, so that you can fix them as fast as possible. Only a small percentage of ts errors are false positives, usually because of some sort of compiler setting.

Having TypeScript compile errors is an indicator of an unstable system. When you start to analyse and fix the compiler errors you will find:

Actual bugs - In a large codebase, you can be sure that there are several bugs caused by TypeErrors
Outdated Libraries
Problematic patterns that were used in the codebase

All of these things have to be fixed eventually. The code quality will be greatly increased when you address these issues. If you do not fix these issues in a timely matter newly introduced errors may be lost in the existing errors and you will continue to waste a lot of time debugging.

When all compile errors are resolved you will experience all the benefits of TypeScript.

The first major benefit is that you cut down your debugging time. By reconfiguring your pipeline to fail as soon as it detects a new TypeScript error, you can prevent most TypeErrors of ever reaching production. This early detection of errors will tell you exactly which line is causing the issue and you then can fix it in a matter of minutes, instead of debugging code for several hours.

With the power of compile errors, you can fix these errors before running your code which in turn greatly Increases your development velocity.

Bonus: Python is maintainable and does not need types

A large Python project is also subject to similar problems like a large JS codebase. To make Python more maintainable Python 3.5 introduced types in a very similar fashion as TypeScript.

https://docs.python.org/3/library/typing.html

Summary

Most of these myths were created by a lack of experience of using TypeScript. It is understandable where the core idea of these myths come from.

Starting to use TypeScript is hard. The reason for that is because you’re starting to think about code differently. You’re starting to take into consideration what datatypes are used. This shift of thinking makes the entire development less error prone.

The reality is, using TypeScript will improve you codebase in many different aspects. The collective benefits far outweigh the negatives.

But, nobody really can be convinced a myth is wrong until they experience for themselves. So go and start using and experiencing TypeScript on your own.

Lessons Learned from a ‘take home’ assignment gone wrong

Neal Burger — Thu, 17 Mar 2022 16:32:29 +0000

Applying for Software Engineering Jobs has really become very strange. I have now been working in the industry for over 15+ years. During this time it seems that hiring has really become broken. Let’s see how I failed this next interview.

The Process

This time around, a recruiter contacted me directly. I had a pleasant 30min chat with the recruiter and was then given a 6h take home assignment to complete and would then be invited to a 1hour technical discussion interview and then after that a 1hour interview with HR - and then they would present me an offer.

I agreed on doing the challenge under the condition that i can publish my result on my blog. Unfortunately I did not get that in writing - and the recruiter then ‘forgot’ our arrangement. I removed all original questions and code references from this article.

The Assignment

Overall a small Admin interface and a view for users should be created. I was given access to a git repo. In the repo i found a working backend in Java or NodeJS server with SQLite DB and working REST-API with Swagger Documentation was provided. In the Readme four very vaguely defined tasks

Task analysis

1. It should look pretty

That the program should be aesthetically pleasing is not the core skill of a developer - it is a core skill of a designer. Even a designer would reject this task as it is too vague and undefined. In a professional setting this would mean creating several different drafts and then reevaluating with the client what style he prefers.

I would assume the company provides their own corporate style-guide you should follow and when working at the company it is more clear on which direction the UI design should be. However for an external person just joining this is not clear.

This is not really a task that a developer should solve. But in the end the biggest problem with this task is that it cannot be evaluated objectively.

2. It should be easy to use

Again a very vague requirement. If you do not know who your target audience is you cannot make it 'easy to use'.

A CommandLine tool may be very easy to use for some users, but adding a GUI may have the benefit that more people can visually comprehend it - equally being easy to use.

Equally there is no mention if it should be used on mobile or web or command-line. Again I have to wonder how will this task be objectively evaluated?

3. Create an Admin Interface

Now we are getting somewhere. Here there is also a little more information: It should contain 2 views, one for assets and one for users.

Sadly in the descriptions functions you would expect from an admin interface are missing. For example ‘delete all assets’ was described, however the api only allowed to delete a single asset at a time (and it probably would make sense to add a delete single asset functionality to the UI.

This task at least can be evaluated objectively. Either the functionality is there or not.

4. Write High Quality Code and add Tests

Again this is meaningless without specific metrics. How is High Quality Code defined? How should the code be optimised? Most pieces of code can be optimised either for memory usage or cpu usage. Which one should you focus on?

Similarly you might want to optimise your code for readability and maintainability but sacrifice memory efficiency. There are always tradeoffs that you are going to make.

Without any clear metric how this task is objectively evaluated. There was not even a hint on how high the code coverage is suppose to be.

Feedback

I completed the challenged after 6 hours. Implemented all functions and a couple of additional helper functions and had a unit test code coverage of around 90%. I used Typescript with React functional components with hooks.

Recruiter: The quality of your solution is significantly lower than that of the other candidates. Is this really the way how you coded at your last company?

Me: I worked around 6 hours on this, just as you requested

Recruiter: Oh, yes thats the minimum - we expect you to be passionate about programming and spend at least 12-18hours on this task.

They then also reversed their decision that I am allowed to publish the question on my blog. They then continued to basically claim ownership over my code, despite that I never signed a NDA.

Of course this immediately erodes any trust in the company. If you are not allowed to publish the solution you can assume a the company wants to claim ownership for your code and use the result of the coding challenge in their own product. - There was probably never a real job, they just used you to provide them with free labor.

Lessons Learned

The next time I will be very careful If i really would want to spend my time doing a take home assignment. I have enough professional experience that should be enough for a company to make an informed decision if they want to hire me or not.

Just imagine using this kind of interview process for any other profession, “oh first show me that you know fix my broken toilet - then i will decide if I will hire you as a plumber”

If the task is so broadly formulated that you can do whatever, you only can fail the task
Get all additional agreements with the recruiter in writing
Don’t work for free for companies

Lessons learned from Technical Interview - Find Pairs in Array

Neal Burger — Sat, 03 Jul 2021 13:56:26 +0000

Here are my notes on a recent Frontend Dev - ReactJS job. There are a lot of lessons learned.

Before the Interview

I was asked that I prepare my editor of choice before the interview. The interview duration would be set to 45min.

I was going to use VSCode and prepared a create-react-app default app.

The Technical Problem

Given an array of numbers arr, find the pairs that add up to the given number k

Clarifying Questions

I only asked a single clarifying question: Is an optimized solution or just a solution that works? Answer: “Haha, well a solution that works is totally fine”

Later this would turn out to be one of my biggest mistakes. I should have asked a lot more questions before I got started.

Implementing the Solution

Instead of using my prepared react project, I choose to use one of my existing code-training projects with a basic Typescript + Jest setup.

Writing Tests

Since the problem is so simple - I decided it would be better do demonstrate my skills and discipline and write tests first.

I choose to write three scenarios: One positive result, no result, and more than one pair found.

This impressed the interviewer. Additionally, the rest of the development gets a lot easier. Your only focus is now that the test suite does not fail.

import { findPairs } from "./addArray"

it('finds positive pairs', () => {
    const input = [1,2,3,4,5,6,7,8,9];
    const value = 3;
    const output = [[1,2]]
    expect(findPairs(value, input)).toEqual(output);
})

it('finds no pairs', () => {
    const input = [1,2,3];
    const value = 80;
    const output:number[][] = []
    expect(findPairs(value, input)).toEqual(output);
})

it('finds positive pairs 2', () => {
    const input = [-1,1,2,3,4,5,6,7,8,9];
    const value = 3;
    const output = [[-1,4],[1,2]]
    expect(findPairs(value, input)).toEqual(output);
})

Solving the problem

My first working solution was a very solution:

iterate over the array
Subtract the wanted value from the current value
If the array includes the value, add it to the output array

export const findPairs = (k: number, arr: number[]): number[][] => {
    let output:number[][] = []
    arr.forEach(firstParam => {
        const searchValue = k-firstParam;
        if (arr.includes(searchValue)){
            output.push([firstParam, searchValue])
        }
    })

    return output
}

This solution solves the problem and is short and simple to read.

Feedback to the solution

The interviewer was not happy. The complexity of the solution is O(n^2). While it did find the correct pairs it found two distinct pairs. For the first test case: [[1,2], [2,1]]Additionally, the interviewer did not like that I used Array.forEach(). I was asked to refactor the code to use the more efficient for-loop and If I could change the code so I only get one pair.

Second Implementation

As requested I swapped the forEach() to for loops. Instead of using Array.includes() - I also am using a for-loop and only am iterating over the remaining items.

The implementation is now at O(n*log(n))

export const findPairs2 = (k: number, arr: number[]): number[][] => {
    let output:number[][] = []
    for(let i = 0; i<arr.length;i++){
        const current = arr[i];
        const searchValue = k-current;
        for(let j = i; j<arr.length;j++){
            const secondParameter = arr[j];
            if (secondParameter === searchValue){
                output.push([current, searchValue])
            }
        }
    }

    return output
}

Feedback to the solution

Well its fine - did not really improve the optimization - we still have 15min time. There is a solution that is O(n) and uses a single while loop. For this you can assume that the array is sorted.

Third implementation

I needed 20min to find the solution. Mostly because the loop did not end correctly. The solution uses two indexes for the array. It then compares the first and last item of the array. If it matches the sum, it gets added to the output array. If not the indexes are adjusted.

export const findPairs3 = (k:number, arr: number[]): number[][] => {
    let firstIndex = 0
    let lastIndex = arr.length -1;
    const output:number[][]= []

    while(firstIndex < lastIndex){
        const firstValue = arr[firstIndex];
        const secondValue = arr[lastIndex];
        const sum = firstValue + secondValue;

        if (sum > k) {
            lastIndex -= 1;
        } 
        if (sum < k) {
            firstIndex += 1;
        }
        if (sum === k){
            output.push([firstValue, secondValue])
            firstIndex += 1;
            lastIndex -= 1;
        }

    }
    return output;
}

Summary

What did go right?

Found multiple solutions
Used Test Driven Development
Had knowledge of the O-notation
Had a backup project available for the interview

What went wrong?

I should have noticed earlier that the output could have multiple pairs
Not asking if the array is sorted
Not asking if the array has unique items
Assuming that a ‘working solution’ is good enough
Stumbling during the implementation to correctly end the while loop

Interview Red flags

A pure algorithms-technical question. No demonstration of ReactJS skills
No feedback from the interviewer that in my test cases the return pairs are incomplete
Interviewer disappointed I did not consider millions of items in my first solution.

End of the Interview

The end of the interview was nice. He pointed out where all I had flaws in the solution. The interviewer was impressed that I could produce 3 solutions in such a short time frame.

He was however very disappointed that I did not consider millions of items in my original solution.

I blew it with my response: “In a ReactJS app usually you do not deal with a million item array, you would send only a subset of the data to the client. Do you have to deal with million item arrays in your application?”

The interviewer was rather embarrassed and said something along the lines of “core algorithm skills” are needed. He admitted in a practical application, with small arrays, the performance increase would be probably unnoticeable.

Needless to say - I never heard back from the company.

Riddler Challenge 01: The case with the switch

Neal Burger — Fri, 18 Jun 2021 13:56:26 +0000

The riddler did it again. He used his superior knowledge of JavaScript to create this incredible piece of code:

const riddlerChallenge01 = (items = []) => {
  const options = [{ value: 'name' }];
  const defaultName = items.find(val => val.isEnabled);
  let output = '';

  switch (true) {
    case Boolean(defaultName):
      output = 'defaultName';
      break;
    case options.length > 0:
      output = options[options.length - 1].value;
      break;
    default:
      break;
  }

  return output;
};

Take your time to appreciate the marvel of the inner workings and the beauty of the solution. We will rewrite the code that the logic is simpler and the next developer can understand what is going on.

First Step: Analysis

Line for line you will have to look for clues and understanding of what the code actually does. While we are doing this, I make mental notes on what to improve.

I’ll add some comments to the code that really stands out and can be improved. Ideally, we would write these comments in the code review so the riddler can fix the issues on his own.

const riddlerChallenge01 = (items = []) => {
  const options = [{ value: 'name' }]; // An array with a single item -> probably should be converted to a simpler variable
  const defaultName = items.find(val => val.isEnabled); // Should use Array.some
  let output = '';

  switch (
    true // Incredible that this passed a code review, with a fixed value the switch is the wrong construct
  ) {
    case Boolean(defaultName): // The Boolean check should be written as defaultName !== unknown
      output = 'defaultName'; //Convert to constant string
      break;
    case options.length > 0: //options.length > 0 => is always true
      output = options[options.length - 1].value; //The array never changes - the string could be used directly
      break;
    default: //unneeded default case
      //unreachable code
      break; 
  }

  return output;
};

Second step: Add tests

By reading the code we could figure out that the function returns a string. We now write tests that simulate all the possible outcomes of this function. This way we get a clear definition of what the functionality of the code is.

This will ensure that we do not break existing functionality when we start refactoring the code.

it('works for no items', () => {
  expect(riddlerChallenge01([])).toEqual('name');
});

it('works with an enabled item', () => {
  expect(riddlerChallenge01([{ isEnabled: true }])).toEqual('defaultName');
});

it('works with an disabled item', () => {
  expect(riddlerChallenge01([{ isEnabled: false }])).toEqual('name');
});
it('works with an mixed items', () => {
  expect(riddlerChallenge01([{ isEnabled: true }, { isEnabled: false }])).toEqual('defaultName');
});

Refactor the code

Step 1: Use a if-statement instead of a switch

The current switch statement works because of the case Boolean(defaultName). Depending on the input it is either true, and then the case gets executed. It does not execute the second case because of the break;.

If Boolean(defaultName) evaluates to false, then the switch case will always execute options.length > 0 as it always evaluates to true. This in turn means that the default-case cannot be reached and is not needed.

The correct way to write this logic is with a simple ‘if statement’.

const riddlerChallenge01 = (items = []) => {
  const options = [{ value: 'name' }];
  const defaultName = items.find(val => val.isEnabled);
  let output = '';

  if(defaultName !== undefined) {
      output = 'defaultName';
  } else {
      output = options[options.length - 1].value;
  }

  return output;
};

Step 2: Remove the options Variable

The variable options probably had multiple values in the past, and is now just a hangover from an older version of the code. As the array only contains a single item and never gets modified > the array should be converted to a string.

In this case we can simply use the variable directly, as the array is not even referenced at any other place in the code.

const riddlerChallenge01 = (items = []) => {

  const defaultName = items.find(val => val.isEnabled);
  let output = '';

  if(defaultName !== undefined) {
      output = 'defaultName';
  } else {
      output = 'name';
  }

  return output;
};

Step 3: Optimize Variable names and readability

The variable name defaultName is misleading as it indicates that it is a string but it used as an boolean. This in turn means that it is better to use Array.some() that returns a boolean instead of Array.find() that returns the object.

I would also rename the variable output to appTitle to make it more clear why we are saving this string.

const riddlerChallenge01 = (items = []) => {  
  let appTitle = 'name';

  const useDefaultName = items.some(val => val.isEnabled);
  if(useDefaultName) {
      appTitle = 'defaultName';
  }

  return appTitle;
};

Note: I choose to remove the else branch of the code as well. This is mostly to mimic the switch mechanism more closely. If you would want to extend it with another case then you would just add another if block.

When you are refactoring code, your primary goal should be that the functionality stays the same, while the code gets more readable and if possible more efficient than before.

What do you think? How would you have rewritten this piece of code?

Lessons Learned from an awkward Technical Interview

Neal Burger — Sat, 12 Jun 2021 21:12:08 +0000

I recently had a rather odd interview with a fintech company. The main goal was to figure out what my React skills are. It was a online live coding session.

Providing the assignment via zip download

The session started out that they provided the source code for this small coding session via google drive download link.

This should be a first red flag. It indicates that management / culture at the company does not allow the usage of GitHub or public repositories. There is not even an exception for the interview process where the code is sent out to the public.

This is something I would clarify during the interview process.

What does the code do?

First step was to get familiar with the codebase and the application. The source code did not provide a Readme.md.

The app generated a large amount of random data and displayed it in a table and added a switch.

My first question was: “What should the switch do? What is the purpose of the application?”

The interviewer could not explain what the purpose of the application is. Or why there was a switch. The simple answer to my questions was: “It is an artificial problem to see your react skills”

At this point, I thought “This is stupid - this will not adequately test my skills. I do not know what is the point of the application. Then there is nothing I can do to fix it.” - I should have listened to my gut feeling and stopped the interview immediately.

The Task - “How would you improve the code”

Oddly the first task was quite a good question. “How would you improve the code” - it is an open question and you can take the interview in any direction. You can see what the candidate values, you can have an open discussion about syntax, libraries, things that are. missing.

In this case there were a couple of obvious improvements:

Using TypeScript instead of JavaScript

You could improve the codebase by using TypeScript. Any long running project would benefit from using TypeScript vs JavaScript. It makes the code easier to read and would at least provide a minimum of documentation.

Interviewers response : No that is not the task for today.

Missing Tests

The application was created using create-react-app. However the ‘tests’ were removed from the code.

This is a very important aspect especially for financial applications. There is usually a high focus on bug free code. The only way to ensure that is to write tests.

Interviewers response : No that is not part of the tasks for today.

Cleaner Syntax

A couple of functions could be written using the arrow syntax.

Interviewers response : That is not the task for today. What is the benefit of using an arrow function?

Here I must admit I stumbled a little bit, because I have been using arrow functions for such a long time - I only remembered that you do not need to think abut the this keyword. (The correct answer would have been: “Does not have its own this bindings.”

The actual Task - “Look at the Performance of the Table”

The interviewer was not interested in an open discussion. He wanted me to find the obvious elephant in the room. The performance of the table is slow.

I failed the first test, that I could not identify the ‘correct’ problem to solve. - My argumentation that the foundation should be fixed first (especially in such a simple app)

Interviewer : When you click on the switch it is slow. How would you fix it?

Me : I would have less items

Interviewer : No, look at how the change handler is written.

I did not expect this answer, I expected that something like pagination should be introduced. Something that is realistic to solve in an interview 30min context.

However there was nothing wrong with the change handler. The problem was purely with the amount of items that are being rendered. I followed the interviewers wish and moved the change handler from the Table component into the Table Row component. - I did not expect to see any improvement. However it actually worked.

Interviewer : No, it only worked because you have a fast computer

Me : Fine then we throttle the CPU.

I had to google then how to get the Chrome dev tools to trottle my CPU, and the solution still worked. However scrolling was still an issue.

The interview goes even more sideways

The interviewer suggests that there is a simple fix for this issue. - Basically adding more stress, as I still cannot see the obvious ‘solution’.

I tried to explain that the underlying problem is the amount of items being rendered - you would have to reduce them by only rendering the items currently visible on the screen. Libraries like react-window does exactly that - its a very complex problem.

There is a reason why every major UI-Library provides its own large dataset table component. It takes a lot of effort to get this right - they expect me to solve it in a live-coding session.

The interviewer reluctantly allowed me to use a library, and wanted to watch me how i select a library and implement my solution.

Aborting the interview

It is an artificial problem that should be solvable with basic React skills - Not by using an external Library. I do not know the answer to this question - this interview is in any case over.

At this point, I stopped the interview. I was being pushed to do things I was uncomfortable with. I still had no understanding of what the actual problem is and the interview was becoming more and more antagonistic.

The final short discussion

I am so glad I ended the interview at this point. I explained that I cannot do this in this short time frame. I only can solve it with more information, clearer requirements and creating a table component to handle large amounts of data would take a month or so to do.

And the interviewer finally revealed what they are looking for: Developers that can solve problems quickly, and create custom solutions.

We are a financial company - we cannot use libraries.

The interviewer revealed a range of problems at this company.

This small company does not leverage open source libraries for their product.
They have outdated concepts of how software development should work.
They are not open for improving the processes at the company.
Instead of working on a solution to have a better way to evaluate libraries they develop everything from scratch.

What was probably the correct solution to the problem?

After the interview I looked at the problem again, without the stress of having two people staring at you and evaluating you.

Probably the answer the interviewer was looking for was that instead of using the Table-component from ‘material-ui’ you should have used the DataGrid-component of ‘material-ui’.

I have never used the ‘material-ui’ library and that solution has nothing to do with my knowledge of React.

In a live-coding session you usually write vanilla-js or some simple React Hooks, something that demonstrates your knowledge. Not a simple switch this component with another component. That does not demonstrate anything really.

Lessons Learned

I should not have ignored the first red flag. The interviewer could not communicate what problem is suppose to be solved. He did not answer any clarifying questions. I never had a chance to provide a satisfying answer.

In an interview the participants have to treat each other with respect. If the interview is starting to become hostile - just end the interview. There is no point in continuing. Just imagine how bad he will treat you when you actually work for him.

I could have saved myself 30min of awkwardness by aborting the interview earlier.

When Clients start to Estimate

Neal Burger — Mon, 31 May 2021 22:27:26 +0000

You are having an estimation meeting with a special guest - the client. He is there to clarify features and any open questions. But during the meeting whenever the client feels that the estimation is ‘too high’ - he says: “Last time this same type of bug, had only 50% of the story points”.

What is a good response?

1. Do not invite the client to the meeting

Well, the most obvious first step is not to invite the client to the meeting. If the client is important to define the task, then have clarifying meetings with the client.

The process of estimating the tickets is an internal developer affair. Only the developers know the codebase and can make any good estimations of how long a task will take.

They are already dealing with the complexity of creating the software - usually they are not involved in how the client is being billed. It does not help that the client bullies the developers to do the work faster.

The client does not know anything about how to develop software. That is the reason he hired your team in the first place. He cannot help with the technical complexity - his opinion of how complicated the task is - is irrelevant.

If it cannot be avoided, invite the client to the Sprint Planning, then he can decide which tasks he wants to spend money on in the next two weeks.

2. You can justify the high estimate

In this case, the client compares this bug to another ‘similar’ bug.

The client is comparing it to a totally unrelated bug

If the client is comparing it with an unrelated bug. Then case closed - the two bugs are not comparable in the first place. They should have different estimations, as they are not related in any way.

The ticket the client has given is not related to the discussion and must be dismissed.

It is related to the first bug the client mention

If you encountered the same bug for the second time, then the last bugfix was not enough. This would be a warning signal that:

a) the last time the bug was not fixed (i.e. the last estimate is useless and additionally the fix needs a correction)

b) there is a deeper problem in the codebase (i.e. the estimate must be higher)

The original fix needs to be analyzed and the deeper problem with the code needs a fix. This will take more time than the simple fix that was done the first time around.

3. It does not matter what the estimate is

There is a very big misconception between “estimation” and “commitment”.

An estimate is by definition not exact. The higher the uncertainty the larger the range of the estimate is going to be. And that is a good thing. - I will get this done in 5-10days.

A commitment is exact: I am going to get this done in 5 days. It is your responsibility to honor your commitment.

With an estimate, you are in no way bound or required to finish the task in that timeframe. If I estimated it is going to take 5-10 days, and the work took 20days. Well then I suck at estimating - but it does not matter, it was just a made-up number.

However, if I committed myself - I am going to do it in 10days. And I miss that deadline I have a big problem. It was unprofessional to commit to something that I could not do.

Clarify this with your client

You should make your client aware that it does not matter what the estimate is. Reducing the estimate, will not change how much time is needed to complete the task. The time needed to complete the task is (hopefully) going to be in the estimation range. In short, his bill will be the same, no matter what the estimate is.

3. Improve your estimations

Estimation methods like Planning Poker have a step called ‘consensus’ where all devs agree upon a specific number. It appears as if the team then comes up with an ‘exact’ number.

Let’s take an example of how this can go wrong:

The devs estimated a ticket. The result? 1x3 points, 1x5 points, and 1x8 points. - At this moment nobody looked at the code or did any further analysis, they only read the ticket description. Everybody invented numbers out of thin air. The consensus for the task will be 5 points. However when reviewing the task after the implementation. It was more complicated than expected and it took the same time as a 12 points ticket.

When the client sees the result of your estimation vs actual cost he is going to be not very happy.

The consensus estimation is useless. A much better approach is to write down your estimate in a range 3-8 points.

Then you can add a second step called commitment. The developer makes a more precise estimation when he starts to implement the ticket. He knows exactly how the codebase looks like and he can do a personalized estimation of how many days it will take him to do the task. (Every developer has a different skillset, thus knows best what his abilities are and when he believes the task will be completed)

4. You are the expert

The client hired you because you are a professional developer. Something went wrong with this team. The client lost his trust in the skills and abilities of your team. Thus he tries to involve himself more.

You have to show the client - that you are the expert. The client cannot estimate tasks for you. He is overstepping his competencies and boundaries.

You must review your estimates to learn how to estimate better in the future. Additionally, you can improve your estimates by doing a code analysis before estimating. And of course, improve your processes (more tests? more manual tests?) to avoid bugs before the client sees them.

5. Do not estimate bugs

Bugs do not need to be estimated. Due to the nature of bugs, any estimation is useless. The developers did not intentionally put a bug in the software. Something unexpected happened, something the developers did not think about in the first place. They need to analyze the situation and apply a fix. Debugging can take hours or mere minutes to figure out what the exact problem is.

It is more important to set the right priorities for the bugs. So it’s clear how high the impact of a bug is. In any case, the developers should fix the bug as fast as possible.

If the ‘bugfix’ mutates into a full new feature. Then do not call it a bug - it’s a new feature or a technical improvement. That is a ticket you can estimate again.

Conclusion

You have to communicate with your client. In this scenario the client probably just had a high priority bug that needed to be fixed ASAP, and he did not have a lot of money to fix it.

You have to work together with your client. That means setting boundaries. Which meetings the client is allowed to attend and where his competencies end. This makes the communication easier on both sides.

How would you handle this scenario?

How many hours should I work (as a programmer)?

Neal Burger — Fri, 07 May 2021 14:44:03 +0000

Uncle Bob in his book "The clean coder" has a very clear answer to his question:

"You should plan on working 60 hours per week. The first 40 hours are for your employer. The remaining 20 are for you. (...) Perhaps you do not want to make that kind of commitment. That's fine but you should not think of yourself as a professional. Professionals spend time caring for their profession."

This is a really bad answer and promotes very bad habits in the industry. If you look at how many hours a programmer works on average it will be in the range from 40-60+ hours a week. Very rarely you will find a part-time programmer.

Let's try to figure out what the correct number is.

Is it harmful to work above 40 hours?

People that constantly working 60 hours are not professional and should consider this:

Assuming you are employed for 40 hours and you work an additional 20 hours - If you would be a freelancer your salary would increase by +50% - however as an employee you will probably not be given a pay raise and you will not get any recognition because your extra work is just assumed as the new 'normal'
You are putting your job as your only priority and will not have time for relationships, friends, family or your own personal interests.
Additionally, you are harming other developers. Two developers working 60 hours a week do the same amount of hours as 3 developers working 40 hours a week. You effectively are eliminated a job opening making it more difficult for a junior developer to find a job.

I bet you are thinking right now: "But there is so much to do, I cant work fewer hours. The project will fail if I do not get all the tasks done. My manager is pressuring me to work long hours"

I am going to let you in on a couple of secrets:

There is always a lot of work, the client will always want a new feature, bugfix, etc. that is the nature of developing software. In most cases, it is not the end of the world if a feature is delivered at a later point in time.
Your manager's job is to get the most work out of you for the least cost. If you work more hours for free, hey that's quite a good deal for the manager in the short term. However great managers will realize that allowing programmers to go home and have a life outside of work will make them more effective at work thus actually improving the project's outcome in the long run.
If you think the project will fail because you are not putting in extra hours, then the projects resources are being miss managed. Management is not aware of the state of the project - You pitching in and doing extra hours, makes the problem worse - as management just believes that the velocity of the project has not changed. You are not signaling to management that the project is not going well and the project cannot continue in this way - they do not know that they are allocating 150% of resources that are available to them. Everything seems to be fine - but in reality, management would have to take action to maintain the project's velocity they either have to hire additional people or adjust the deadlines to match the available resources.
And finally, the deadline for the project is probably arbitrary. Any project manager knows that things go wrong in a software project. You can assume that there are multiple fallback deadlines. Even if there is the 'last' deadline - you are dealing with people and people can be flexible if you communicate with them - also if they already invested months of time and resources into a project, in most cases you do not throw that away immediately.

Overtime is sometimes unavoidable, but it always should be a temporary measure, never a permanent state.

It should not become a permanent state because studies have shown that most humans when working more hours just work less efficiently. So it is very likely that you can work fewer hours and achieve the exact same outcome because you are working more focused.

In short - you should only be working more than 40 hours for a good reason.

Working for 40 hours is also bad

If you think you can clock in from 9-5 and just work on your tasks - you will burn out.

You have to stay up to date on what is going on in your field. You have to learn multiple programming languages. It is your responsibility as a professional developer.

Managers will not take care of this. Most times they will promise you 'trainings', while at the same time they will never have the budget for you to actually attend a training.

"But learning a new technology that my employer does not need is just for me"

Let's assume you learn an abstract programming language like Piet - It seems useless for your employer at first, but maybe at your company for the problem that you have to solve this language may be the easiest solution. It also may be that this technology makes the problem harder and you should avoid using it.

No matter the outcome, you the developer will have sharpened your skills have a deeper understanding of the technologies being currently used by contrasting them with the newly learned technology. Additionally, you gain knowledge about technologies you might want to consider or avoid in the future. With the side benefit that you are less frustrated at your job because you know your skills are growing.

But without your effort in learning about the technology, your employer cannot make an educated decision and will just go with whatever they have always been using. The manager may not even be aware of this new technology. In the end, it is your job to explain to your employer if they should use technology or not - they rely on their employees to highlight the potential benefits/downsides of using any tech.

You have to plan this time, it's part of your self-management - just as you would plan time for your emails. It's just part of your job, your manager will not tell you to answer emails, it's just part of your job to do that, the manager assumes that you know that.

If you only dedicate 40 hours to complete the tasks that your employer gives you, you are neglecting your skills why your employer hired you in the first place - and risk to be replaced.

Programming for 20 hours from 9-5

Now, let's take a look at my ideal view of how you should spend your 40 hours a week:

20 hours is for working on actual tasks
10 hours is for practicing skills and keeping up to date
10 hours is for meetings, email, and socializing

25% of your time spent on practicing seems excessive. Coding is equally craftsmanship and artistic expression. Consider other professions like a concert musician. A violinist would be practicing for months for a single concert - 99% training and 1% performance. Nobody would say that is excessive.

Note: Practicing skills means actively learning and solving problems it is not passively watching for hours YouTube talks or listening to podcasts

Meetings in an organization simply take time a lot of time that you are not spending programming, and many times you get the feeling you were in so many meetings you did not get anything done for the day and clock in an extra hour - however attending meetings is work. you did get something done - you are allowed to go home you may not have done fun things like coding - but you did work.

If you miss a deadline because of a meeting then you maybe should reconsider if you should've attended that meeting in the first place. nobody's forcing you to attend every meeting. If your manager complains that you're not going to attend a meeting then you can explain that you have a deadline to meet – The manager can then decide what is more important. You are the one that has to inform your manager about the conflicting responsibilities.

The remaining time you can spend working on tasks and that is if you are lucky around 20 hours.

But I am passionate about programming

You can program as a hobby even while you're working in the field. But then you have to treat it as a hobby and you only should do it if you have the time and it gives you joy and satisfaction. - this also means working on your own project - not work-related and overall it should be relaxing.

Quality over Quantity

It all comes down to quality over quantity. It is better to commit to fewer tasks and deliver them on time and in good quality than deliver many tasks with bugs. Because the bugs will drastically reduce your development velocity over a long period of time.

And in the end, your manager will also be happier because your work output becomes more predictable and reliable. As a bonus, the manager does not have to explain to people why the software was created with so many defects and then order overtime to fix them as fast as possible.

Working focused we get you much further than overworking and neglecting your life outside of work.

There is no correct answer

You have to think about your personal situation and work the way it suits you.

Take your time to think about your current situation, your capabilities,
and set your priorities.

Take responsibility and control over how many hours you work. This is an active choice - do not passively just do that what everyone else is doing.

What do you think? How many hours do you work?

A case of premature optimization?

Neal Burger — Thu, 06 May 2021 10:36:40 +0000

Recently I ran into an interesting problem in a live coding session. The interviewer found a problem with my code and asked me to improve the code. Take a look at the following code. What do you think can be optimized?

const HeadLine: React.FC<{ text: string }> = ({ text }) => <h1>{text}</h1>;
const TextBlock: React.FC<{ text: string }> = ({ text }) => <p>{text}</p>;

export interface Item {
  type: 'Headline' | 'Block';
  text: string;
}

export const RenderBlock: React.FC<{ block: Item }> = ({ block }) => {
  const { text, type } = block;
  const RenderMap = {
    Headline: () => <HeadLine text={text} />,
    Block: () => <TextBlock text={text} />,
  };

  return RenderMap[type]();
};

Solution

When you use the RenderBlock component, the constant RenderMap is going to be recreated every time the component is used. You can extract the constant and put it into a higher scope to solve that problem.

The optimized code would look like this:

const HeadLine: React.FC<{ text: string }> = ({ text }) => <h1>{text}</h1>;
const TextBlock: React.FC<{ text: string }> = ({ text }) => <p>{text}</p>;

export interface Item {
  type: 'Headline' | 'Block';
  text: string;
}

const RenderMap = {
  Headline: (text: string) => <HeadLine text={text} />,
  Block: (text: string) => <TextBlock text={text} />,
};

export const RenderBlock: React.FC<{ block: Item }> = ({ block }) => {
  const { text, type } = block;
  return RenderMap[type](text);
};

How much did we improve the code?

If we benchmark a similar piece of code with js.bench we can see a 15% performance improvement. Technically we can see a real-world improvement. More operations can be done in the same amount of time (390000ops vs 400000ops)

The downside is that the code is harder to read (it is not reading a single block but jumping up and down in the code) and harder to extend (if parameters change for example).

In a real-world environment, you probably will have a maximum of 100 instances of this component. By optimizing the code we probably will save only a couple of microseconds.

I would argue that this is a case of premature optimization. It will not have any noticeable benefit for the end-user, while at the same time make the developer experience worse. This is an issue that would be needed to be discussed with the team to further define the style of how the code is written in the codebase.

In the end, this is a coding interview, so there is no real debate. The interviewer is expecting a certain solution. Even if your solution is correct, it might not be correct because you did not match the values and expectations of the interviewer. – I probably should have answered: “Not everything that can be optimized should be optimized.”

Originally published at https://codeandchaos.com/excercise/jobinterview/2021-05-01-ReactOptimizationQuestion/ on May 1, 2021.

A comprehensive guide to the FizzBuzz-Problem

Neal Burger — Mon, 31 Aug 2020 00:00:00 +0000

Lets explore the classic FizzBuzz-Problem. What is the problem? What is a potential solution? Should you use it in an interview context?

The Problem

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

This is a Math problem. At the core this is a problem of finding the numbers that are divisible by 3 and 5.

You will demonstrate that you are knowledgeable about following topics:

The Modulo Operator
Loops
How to output to the console in your chosen language
How to write a function and how to use variables

The FizzBuzz Solution

Now there are many different ways to solve this problem. I will present you a couple of solutions:

The Common Solution

const fizzBuzz = (): string[] => {
    const result: string[] = [];
    for (let i = 1; i <= 100; i++) {
        if (i % 3 === 0 && i % 5 === 0) {
            result.push('FizzBuzz');
        } else if (i % 3 === 0) {
            result.push('Fizz');
        } else if (i % 5 === 0) {
            result.push('Buzz');
        } else {
            result.push(i.toString());
        }
    }
    return result;
};

What is good about this solution?

It solves the problem.

What is bad about this solution?

It has a magic number 100
It duplicates the modulo operators
It is difficult to test

The Optimized Solution

const fizzBuzz = (n: number = 100): string[] => {
    const result = []
    for(let i = 1; i <= n; i++) {
        const divBy3 = i % 3 === 0;
        const divBy5 = i % 5 === 0;
        const str = `${divBy3 ? 'Fizz' : ''}${divBy5 ? 'Buzz' : ''}`;
        result.push(str || i.toString())
    }
    return result;
}

What is good about this solution?

It is very efficient.
It stores the values from the modulo operations in variables.

What is bad about this solution?

It is difficult to test
It is hard to extend with more numbers.
Abbreviations for variable names.

The Solution I Would Like to See

This solution represents my personal values. The code needs to work. Additionally I would like to see the solution as readable as possible. I do not care about the performance or if the solution is the optimal one.

Unlike most people I am using two different functions to solve the problem. I am optimizing for testing. By writing two functions it is easier to test the logic. In fact in an interview situation I would follow up and ask the candidate to write test cases for the logic.

const fizzBuzz = (n: number = 100): string[] => {
    const output: string[] = [];
    for (let i = 1; i <= n; i++) {
        output.push(convertToFizzBuzz(i));
    }
    return output;
};

const convertToFizzBuzz = (n: number): string => {
    const divisibleBy3 = n % 3 === 0;
    const divisibleBy5 = n % 5 === 0;
    if (divisibleBy3 && divisibleBy5) {
        return 'FizzBuzz';
    } else if (divisibleBy3) {
        return 'Fizz';
    } else if (divisibleBy5) {
        return 'Buzz';
    } else {
        return n.toString();
    }
};

What is good about this solution?

It is readable.
It is testable.

What is bad about this solution?

It is not efficient.

The FizzBuzz Problem in the Context of a Job Interview

It is quite common that during a job interview, instead of going into a full technical interview, you are asked to solve the FizzBuzz problem on a piece of paper. It is used as a smoke test to see if the candidate has basic coding skills.

The Fundamental Problem with FizzBuzz

It is quite unlikely that you need a developer that can solve Math Problems. While many developers have good math skills it is usually not the type of problems you will have to solve on a day to day basis.

When you are interviewing a recent graduate - what is the point of the question. He probably will not have gotten his degree if he cannot code. In the worst case you will have to train him on the job. But that is the risk of hiring a student.

On the other hand if you are asking this question to an experienced developer - it really does not prove anything. You may expose that he did not work on math problems recently. It does not expose his thought process or his capability to solve problems. You stripped the developer from common tools.

What does it mean when the candidate cannot solve the problem?

The one thing I have noticed in interviews when this question was asked. In most cases the candidate was not familiar with the modulo operator.

You then could argue the candidate should be able to solve the problem without the modulo operator. The candidate could use something like Math.floor(n / 3) === n/3 or Math.floor(n / 5) === n/5 to find the numbers that are divisible by 3 and 5.

This line of thought is flawed. The candidate does not have a lot of experience solving Math problems. Thus it does not matter if he knows modulo or can work around it.

What can you learn from the candidates solution?

The most important thing is to concider that the solution will be written as throw away code. It does not have to fulfill the requirements of the code you write for your project. Thus it actually does not matter which solution the candidate presents.

Further on you anyway cannot learn a lot from the code the candidate writes. The problem is now so common in interview preparation materials, that it is not worth asking the candidate to solve the problem. There is a high chance the candidate memorized it.

If the candidate is not familiar with the problem - he wrote the code under pressure and stress - which probably did not create his best work.

Conclusion

If you want to ask the question in the context of an interview, really ask yourself “What exactly do you think that you will learn from this question?” - The time in an interview is limited, don’t waste it.

It is a good small interesting exercise to think about. Especially to write variants of FizzBuzz just to see if you can find a different solution. (There is always going to be a tradeoff)

FizzBuzz is a classic interview question. But it is a question that probably should be left to the history books.