What is the minimum...

Hello all,

I would like to hear from both junior and senior level developers on what are the minimum programming skills needed to become a developer. I am looking for more than just the basic answers, "Know HTML, CSS, JavaScript, Git, Node, etc.". We can Google everything, so what do you need to know without Googling? I am looking for specific level of knowledge needed.

Thank you all in advance.

Comments

[Daniel Cunha (he/him)]

Short Answer: Know how to build a CRUD.

In my perspective, once you get how to build a CRUD, you're a developer! People overthink things saying that you need to know a set of tools in order to work or get the job.
Why a junior dev should know by heart technical concepts, pros and cons? How much experience they have to state something they haven't experienced yet?

I usually say that there are topics juniors are not prepared to understand. And that happens to every level of seniority!

Some might say that I'm crazy or that I'm not a good professional... But why recruiters still requiring an extensive list of skills, frameworks and even 3 years plus of experience for juniors?
Building a CRUD has enough complexity to learn how to develop quality software! Then, as it goes, you'll see that new knowledge will be required in order to make that software better and better!

[Doug Parsons]

This is a terribly difficult question to answer. Every in-person interview is going to be different, each hiring manager is going to have different "things" they are looking for, etc. Let's take a swing at this though and see if we can get you an answer that is worthwhile.

Let's assume that you apply for a position that you are qualified for and you are granted a face-to-face interview (I am assuming you are a JS dev based on the tags). The interview has three parts: some technical questions, a coding exercise, and a white board session.

So, without Googling, how well would you do here:

What are the data types that JS supports?
What is the difference between double bar and triple bar equality?
Explain what the DOM is.
What is negative infinity in JS?
How would you declare an object with 5 fields?
What is a promise?
What is the difference between a GET and a POST request?
What is an async request?
What is a function callback?
What is use strict and why would you use it?

Maybe you did ok here, you are feeling pretty good, the ice has been effectively broken and you are ready to move on to the coding exercise portion. In come two senior developers with a laptop and sit down with you. They inform you that they are going to give you a choice on what your coding exercise is going to be. You can't use Google and they are going to be sitting in the room the whole time with you as you code. They present you with the following options:

• In a language you are familiar with, write a function that takes in a string of Arabic Numerals (0 - 9) as a parameter and returns a string that is the roman numeral representation of the provided number. As example: convertToRomanNumeral(1999) would return MCMXCIX.
• In a language you are familiar with, write a bubble sort.
• In a language you are familiar with, without sorting an array of random integers, find the second largest value.

How did you do? Maybe you rocked it and are just waiting for the last phase: the white board session. In walks the hiring manager and a solutions architect, they sit down, and ask you to white board out, in psuedo-code, how you would build an elevator system.

The interview ends. How did you do?

This is obviously rhetorical but the point is how good are you at solving problems? Can you fumble through it or are you going to be at a full stop without Google? If you can't solve problems without Googling the problem you aren't going to get to far. If you haven't coded in front of someone, where they are grading you, it is way more nerve racking then you might think.

Every coding exercise is going to have some level of variability to it and no matter how much preparation you do, some hiring manager is going to throw you a curve ball that you have never thought about or practiced. How are you going to do?

Entirely anecdotal: my first "real" programming interview was 4 hours long. I walked in, got through the behavioral portion of the interview, and then the hiring manager gave me a laptop with instructions on what to build. Over the course of 4 hours I had to build a web site that connected to SQL Server and executed a series of CRUD stored procedures. The website had to read the data from the database, display it to the user, allow the user to add rows to the database, and edit existing rows.

Programming is all about problem solving. As long as you are good at solving problems in whatever language you use, you will do fine.

[Thomas Werner]

After collaborating with several different kinds of developers with varying levels of skill, here's a list of skills I find very important:

A dev should know how to...

• Read and understand an existing code base
• Put their own code style preferences aside and adapt to the style and coding conventions of the existing code base
• Have a grasp and appreciation of clean code
• Identify similar problems and apply common solutions without duplicating existing code
• Fix "undefined" errors or null pointer exceptions
  • This is one of the most common bugs that is usually easiest to spot and fix
• Read a stack trace / error message
  • Identify which component crashed, how to find the file and line number
  • Identify or isolate possible causes
  • Understand the technical terms that are often in an error message (e.g. index out of bounds)
• Efficiently use the IDE
  • How to find classes, methods, functions, pieces of code?
  • How to use code completion, code generators and refactoring tools
• Use a debugger
• Write useful code documentation and comments
• Set up and troubleshoot their tools and workstation
• Understand Git or version control basics (branching, merging, rebasing, resolving conflicts)
• Write useful commit messages
• Take notes and write down lessons learned and troubleshooting steps for later reference
• Communicate from developer to developer (i.e. learn the correct terms for their tech stack)
• Communicate from developer to non-developer (i.e. how to explain something with non-technical terms)
• Ask for help when stuck (not everyone does that)
• Figure out when they are really stuck
  • Some people always ask for help when there is the smallest obstacle that could be easily resolved by googling
  • Some people google all the time and cannot find the right answers

And ultimately a good dev should know how to google. Coming up with good search terms and knowing how to filter through relevant and irrelevant search results is actually an important skill

[Irkan Hadi]

Senior developer here, short answer: learn programming logic (syntax independent) and then practice one or more language / tech-stack until you get good at it.

Long answer: It really depends on who do you want to call you a developer. Do you want to do it for yourself and freelance? then pick a tech stack and learn it and make multiple projects with it until you are good at it.

If you want to join a specific company then reach to them and ask them about what tech stack do they use and what kind of skills do they need and work on those

Truth is, there is no set-in-stone definition of what "developer" means, I know some people who code in VBA in excel and call themselves developers (I code in VBA from time to time as a business requirements) and other developers build end-to-end full-stack solutions (front-end, middleware, back-end), I do those as well. So really, it's a wide range.

And as you said, we can (and we do) google a lot, but some stuff like logic and how different components integrate and interact with each other is a skill that you need to learn since its not something that you can easily google and apply on your the fly (unlike syntax where you can easily check the online docs and get some insights and apply on the fly)

Also, you have to be prepared for a life of constant learning because even if you master a tech stack today, tomorrow it might be obsolete and you will need to learn new things. Development from 5-10 years ago is a lot different than what it is today.

Final piece of advice, start small and grow slowly, don't overwhelm yourself.

[Scott Provence]

Thanks everyone for the feedback here!!