What is wrong with new generation of programmers?

30 points by anshumanravi 10 years ago | 58 comments

I have been interviewing programmers for last couple of weeks for full stack developer position,And really disappointed with quality of answers I've got so far .

I figured out a common trait among almost all whom I interviewed , They seems to know 'What it does' but dont know what it is or how it does.

For example, They do not know what database indexing is or how it works(They know what it does though, improve query performance, wow!)

Ask them few intermediate level sql queries to write and they would be like I did it using ORM of framework xyz.

Or at programming language level, I asked what singleton is, they replied correctly about what it does, but failed to answer how it works, and interestingly answer were different from 'experts' of different language or framework, ROR guys said it works probably by installing gem, PHP guy attempted to write class but couldnt , javascript guys usually like 'meh, I dont know'

Asked them about REST and all would correctly recite its verb and full form, but would fail miserably when you want to know from them what is purpose of doctype, Or how http works under the hood or sometimes they dont even know what is GET and POST.

I remember things were different around 10yrs back, People used to write lot of code from scratch and had less tools, I am not blaming tools or framework for it, but new gen programmer seems to be so dependent on tools that they dont even care to know about whats going on under the hood. they would just read few blogs, read tutorial of framework/tools and start calling themselves expert.

EDIT : Formatting

YuriNiyazov 10 years ago |

You hear very often that the programmer industry is "age-ist", in other words, the older programmers have a hard time getting hired.

This post is the other side of the coin: older programmers think that when they entered the industry it was "the golden era", and everything since then has gone downhill. This is akin to someone in the late '90s asking all entry-level programmers "you mean, you don't regularly disassemble your object code to verify that the compiler did the right thing? What's wrong with you, why are you relying on your tools so much?"

The fundamental issue is that the industry is maturing, but the names of the positions for which you are hiring hadn't quite kept up with what you are looking for. People whose primary job is to make sure that data gets from the database to HTML and back really don't need to know what is under the covers. This position is called "product programmer". Their job is to translate whatever your UX guy cooked up into things that actually work. If you then need to make sure that whatever they made scales up to thousands of requests, you need to have a different person called a "performance developer" - these people really hate translating UX wireframes into code, but once that part is done, they can optimize everything up and down the stack with their eyes closed.

Also, this is a personal pet peeve of mine: if you are asking what a singleton is in a job interview, you are interviewing for the wrong thing, so no wonder you are getting the wrong interviewees.

ChemicalWarfare 10 years ago | |

Pretty much everything the OP mentions is reasonably basic "core IT" concepts. Depending on what he means by "intermediate sql" that might or might not fit into that category. I don't think it's unreasonable to expect a "full stack" dev to have at least a basic understanding of things like DB indexing, singletons, http get vs post. Where I would agree with you is to become proficient with these concepts it does involve spending some time in the industry so the age thing might be the factor here as well. Personally I would strongly prefer these types of questions to the "recent CS graduate" type questions some companies are notorious for and not just because I can answer these :)

YuriNiyazov 10 years ago | | |

When people say "full stack", it means something very specific to me.

It means you can do both UI and server code, so you have a wide variety of knowledge in the many competing front-end and back-end frameworks out there, but you are not quite an expert in anything. At your last job you learned all the magic incantations of jQuery, Rails and MySQL, but but today you are expected to learn all the magic incantations of React, Node and Mongo. Specifically because you are expected to change your toolkit quickly, you do not dedicate any time to scratching the surface.

Certainly when hiring for "back-end developer", I expect deep knowledge of OS- and DB-level concepts like indexing and garbage collection.

Likewise, when hiring a "front-end developer", I expect deep knowledge of various mobile, desktop and tablet devices and the behavior various browsers exhibit on them.

smileysteve 10 years ago | |

> Also, this is a personal pet peeve of mine: if you are asking what a singleton is in a job interview, you are interviewing for the wrong thing, so no wonder you are getting the wrong interviewees.

I have to agree.

The database indexing "how" also seems to fall into this; Maybe you understand what the limitations of the decision are, but even this is moving more into Architect or DBA roles.

Delmania 10 years ago |

How well do you understand an internal combustion engine?

Do you know it well enough to be able to diagnose an issue ad then fix it? Can you listen to it, identify when it's not performing well, and then make the tweaks to it in order to get the most efficiency? If you say yes, I would be very surprised, and yer every day, people all over the world rely on these things to get them to the place they need to go.

There is nothing wrong with these developers, they don't know these things because they simply do not need to. The tools have abstracted away those details, as they should. There is simply too much in the domain of writing software to know, and even in web development, there is too much to know. Most people focus on what is needed to get the job done because in most places, you are judged by your results and not your knowledge. What good is know what a singleton is if you never use it? Why do people need to know what the doctype does when <!DOCTYPE html> is good enough for the browser to interpret? By abstracting away these details, people can focus on higher level problems, like solving the actual requirements.

If people need to learn those things, they will do so.

Good developers seek to learn about their tools. Great developers learn to separate out the wheat from the chaff and focus only on the knowledge that is important.

sharemywin 10 years ago |

So, your offering a job rewriting the internet...that's pretty cool. Oh, right it's just another CRUD job. Also, why not write all your interview questions down on a piece of paper and leave them for an hour with internet access. If they still can't answer your questions then you have a problem. And, if there a gaps maybe train them a little bit. I think if everyone stopped wasting so much time looking for ninjas, experts, and unicorns and started hiring people the world would be a lot better off.

aprdm 10 years ago |

I've recently interviewed in 10+ companies (interviewed as went to the last part of the process) and just changed jobs.

I have a degree in computer engineer and 5 years of experience, what I have to say:

1. In the interview process I always feel really hard to know how deep I should go in the answer... I had the same design an short url service in two different companies, one complained that I went too deep and didn't talked about the thing on a system level too much. Other said I didn't went too deep and looked like over heardish as I focused on the system level.

2. I've studied a lot of algorithms and data structure as every company thinks they are google and asks for big o notations, algorithms optimisations, implement a tree, reverse a tree blablabla. This part was the easiest in all companies as I "gamed" the system by studying it weeks in advance. Does it make me a better developer? Probably not, I already knew that stuff but if you asked me to go deep in those questions when it wasn't fresh in my mind I wouldn't be able to develop an answer. I am pretty sure that 6 months from now I won't be able to answer them in a satisfactory manner

3. I had the same singleton question and I didn't answer correctly, gave an answer like you said. Basically, I know what a singleton is, I've used this pattern in the past. Even in a C++ embedded systems app running in a touchscreen + ARM. But, please, don't ask me nuances about it. If I really wanted I could just game it as well by reading some cracking the interview questions on design patterns.

The best interviews I had were a CHAT where I talked about previous project, challenges and etc.

Not some question / answer quiz game where the interviewer is in a position of authority and I am always concerned that I am giving the answer he is expecting.

autoreleasepool 10 years ago | |

You're forgetting not everyone could game the system like that. Not everyone is as motivated as you, either. These tests (even if they are contrived, unrepresentative of real work, and gameable) give desirable results.

A test who's only flaw is that motivated individuals with good problem solving skills could "game" if they worked hard enough?

That sounds like a good tool for finding strong candidates to me.

ralphael 10 years ago | |

Well said, I interview a lot of developers and always refuse to add to our interview process or ask any questions where the candidate could easily google the answer.

We will do a basic phone interview, to seek out what they know about the areas we work in and then dig - explain how it works and why how we would use it?

Then its a technical test if they pass the phone interview. Now demonstrate some the concepts we previously talked about.

nabla9 10 years ago |

First you should look at the job advertisement and the money you offer. You might be missing the people you want and getting what you pay for. I don't think the number of people with deeper knowledge is smaller than 10 years ago. There are more jobs and more people after those jobs while the number of people who know their stuff stays the same.

If you pay less than 75% percentile for programmer job, you can't expect too much.

Occupational Employment and Wages, May 2014 15-1131 Computer Programmers http://www.bls.gov/oes/current/oes151131.htm

brianwawok 10 years ago | |

Yes, would be curious to see his job posting and what he is paying. If you are paying average wage, you are going to find (at best) the average programmer.

Also you need to be aware of self bias when interviewing. You ask him things YOU think are simple, and are shocked when they don't know it. Of course the only sane way to do A singleton object in Java is to do a double checked lock with a volatile keyword, it says so right in "java concurrency in practice!"... But if a candidate has never needed to write a hand rolled singleton (say always worked in Spring), meh.. I bet they know things that you don't know. Ask a candidate you reject as dumb to ask you 10 hard questions he can prove he knows the answers to, and see how many you get right. If he stumps you on all 10, then you just proved that you each know things the other does not, which may mean you would be a good team working together ;)

P.S. I know how DB indexes work because I find it interesting. Does that actually help me? So far I have never used that knowledge, but hey - I sound cool in interviews!

anshumanravi 10 years ago | | |

>You ask him things YOU think are simple, and are shocked when they don't know it

No I ask him things that He wrote in his resume He is expert of, One need to understand,Process of interview is not riddle game, or I am not going to play role as Brain magician who would through questions to candidates just for fun.All I am expecting from a candidate is if you are presenting yourself as an expert of field, be prepared to answer 'what' and 'how' of it.

confused_cto 10 years ago | | |

I love your reverse interview idea. I am gonna start doing that (:

joeevans1000 10 years ago |

There's a lot of demand for programmers. In the marketplace, there are tool makers, and tool users. Some people make and use tools, of course, but for the most part workers will fall primarily into either camp. Naturally, tool makers are more expensive. It's possible the OP is paying a tool user rate and wants a tool maker. Due to the high demand for tool makers they are expensive.

Scarblac 10 years ago |

Ten years ago the stack was much smaller than it is today.

If this is the "new generation", they probably have little experience. And you want "full stack" developers -- that's a really tall order, most people will work in a team where some people do one side and others do the other.

So you're looking for people who have little experience, and are still more about all aspects of this huge stack than just how to use it. It's not realistic.

Also, you're both blaming them that they are dependent on tools, and only asking them questions about various tools.

hiram112 10 years ago | |

Exactly. I was concentrating on backend the last few years and didn't have much frontend tasks. I recently switched to a new project that was developed by a generally younger team, and it's way more complex.

Instead a JSP / ASP / Rails template files with a single CSS and JS page, along with JQuery and a few libs, there is a whole build process with dependency hell and a dozen tools to master - bower, grunt, npm, karma, etc.

Writing the frontend with promises and async patterns is actually more difficult than the backend which has been slimmed down to basic Rest -> Service - DB calls. Honestly, I'd probably do pretty poorly on an interview too, these days, if a 'Ninja Full Stack' dev. was desired.

maxxxxx 10 years ago |

I see the same with new guys. When they need to calculate the intersection area between a few rectangles they spend hours looking on GitHub instead of writing 50 lines of code. And they have no idea how even a simple linked list implementation could look like.

There seems to be something in the training that tells them it's not cool to implement things themselves, instead only libraries are OK.

Johnny_Brahms 10 years ago | |

I have had the same experience. Give them an API and they glue things together like there is no tomorrow, dealing with edge cases I probably couldn't have come up with on LSD.

Ask them to fix a bug in a procedure using call/cc, and in the best case they will rewrite without call/cc 3 times as long.

xsmasher 10 years ago |

The people you want are still out there, but either you are not filtering for them, or some filter is keeping them out.

For junior candidates we use a written test followed by a phone screen to avoid inviting time-wasters and resume spammers into the office; We're sometimes flexible on that for candidates who clearly have relevant experience.

alexandercrohde 10 years ago |

I think this generation shift isn't new, and I think it's "standing on the shoulders of giants." It's what makes each generation more effective than the last.

Specifically, I've worked with very smart individuals who grew up working on ARM processors and when tried to transition to javascript had difficulty with something like Ajax. I being one generation younger, am somewhat oblivious of ASM, hard disk sectors, etc, but since the abstractions aren't leaky it actually let's me focus on more theoretical stuff.

Moreover, I think one generation from now things like caching will automatically be decided at the storage-engine level, and things that are now manual-work will become abstracted away allowing engineers even greater productivity.

edit: clarity

0xdeadbeefbabe 10 years ago |

I think they aren't being lazy, and they've adapted to a culture that wants things finished quickly at the expense of quality, or anything else really.

Edit: The same culture doesn't recognize that "done" implies a certain level of quality.

bdcravens 10 years ago | |

This. "Lean" and "agile" emphasize feedback and iteration over great engineering. For a large number of apps, that's acceptable.

dragonwriter 10 years ago | | |

"agile" and, especially, "lean" emphasize feedback and iteration as tools to achieve quality and fitness for purpose (i.e., "great engineering".)

They do not emphasize feedback and iteration over quality.

maxxxxx 10 years ago | |

It's also a culture of no training.

mattkenefick 10 years ago |

Lately, instead of greeting people with "Hello" or "Hey man," I usually start off all my conversations with this speech.

I agree so much so I had to double check that I didn't actually write it.

officialchicken 10 years ago |

"How do you deliver software your users/clients want?" is really the only technical question you should need to ask the 10+ crowd.

The highly-experienced type of dev who could easily walk out of the interview and become your next competitor is the one you want to hire.

So, would you ask a competitor questions about one pattern, inner vs. outer joins, and naming conventions? Or would you use that time to actually learn/discover info about your (potential) competitor?

cwt 10 years ago |

I don't think you should limit this to the "new generation." I am at around 5 years experience in the dev workforce and believe I can answer those questions to a satisfactory degree. From interviewing and professional experience these are questions that seem to give everyone trouble. I interviewed a guy with 15-20 years of experience and he didn't understand B-Trees and indexing but his mentality was: why should I bother? that is the DBAs territory.

Obviously, my background is different. I think this is the root of your issue. Most people are learning what they need in order to get a job completed. Most of the time it doesn't involve them having to build the entire application, they are asked to work on a small portion.

All things considered, I agree that devs should understand more in depth the core components of web applications.

cblock811 10 years ago |

Your last paragraph resonates with my experience learning. After two years of working with Rails I realized it's like the Mac of frameworks. It does so much to prevent me from thinking or looking under the hood that I don't actually know what's going on. So part of my reading this year is on topics like REST so I actually get it, and also building things without a framework (rather than use the devise gem, build my own login system, build own router, etc). It's pretty painful because I'm so used to effortless progress through gems, but very worth it.

I think people in my situation just get comfortable and forget that they need to keep digging deeper. I think this also differentiates someone being just a programmer vs an engineer.

bdcravens 10 years ago |

> I remember things were different around 10yrs back

You say you're hiring for a "full stack developer". I'd say that requires far more broad knowledge than a developer 10 years ago, when we tended to specialize back-end/front-end/ops.

kluck 10 years ago |

OP's question is a generalization over a whole generation and can thus hardly be true.

What might be true though is that knowledge in software programming is much more specialized than a couple of years ago. IMHO that is a sign of a growing industry.

That aside I have the feeling that some people did not have the pleasure of a good education in software development, which is the reason they miss some of the more fundamental bits (or they did not pay attention which is another issue). That may be due to the fact that it is easier for lesser-educated (sorry for my english) people to get into software development and that may be due to great demand for developers in general.

qwertyuiop924 10 years ago |

What's wrong with them? Their magic line is too high :-D. You should probably read Steve Yegge's posts about it[1][2], he explains better than I could.

1: https://sites.google.com/site/steveyegge2/practical-magic 2: https://sites.google.com/site/steveyegge2/age-racecar-driver

JSeymourATL 10 years ago |

Perhaps your interview process is suboptimized for finding talent.

Google famously struggled with this issue. They found the best predictor of how someone will perform in a job is a work sample test (29%).

This entails giving candidates a sample piece of work, similar to that which they would do in the job, and assessing their performance at it. Even this can’t predict performance perfectly > http://www.wired.com/2015/04/hire-like-google/

eecks 10 years ago |

I would probably fail your interview but at the same time I could probably join your team and be one of the best members of that team. Funny how that is possible.

I would definitely fail the singleton question but if it came up in work (and it hasn't for me) then I would either ask someone or look it up and then I would know it.

EDIT: Although to contradict what I said above.. I would do intense study before interviewing for a job I wanted so I would probably do well..

halis 10 years ago |

Programmers are expected to know about more than ever before. There are more abstractions than ever before. While I wouldn't let a senior developer get away with not knowing those things, I would give beginners and intermediate developers some leeway.

I would opt to learn how much code they've written and their general programming ability over trivia.

If they are smart and capable, they can dive into the details of any challenge that comes their way.

trumbitta2 10 years ago |

Somewhat related to the general discussion I'm reading in the comments: https://www.williamghelfi.com/blog/2015/12/26/william-versus...

27182818284 10 years ago |

This reminds me a lot of what mxcl went through with Google

https://twitter.com/mxcl/status/608682016205344768

babakkhan 10 years ago |

I do not believe you have to know what happens inside. And concept of blackbox in engineering actually comes from this insight. But the approach to solve a problem is more important. That is why debugging a code is blamed in testing.

anshumanravi 10 years ago | |

When I say, candidate should know what happens inside, I do not mean he should be knowing all minute detail of it, but a generic high level understanding of tools/framework being used is expected so if required one would not hesitate to go under the hood and try to find problem.

cyphar 10 years ago | |

Black boxes are bad. Yes, you can build things. But you don't know how it why they work, and when they stop working you don't know why because you never knew why it worked in the first place.

seekingcharlie 10 years ago |

We've been taught by the "old generation of programmers".

Think about it.

kaendfinger 10 years ago |

Sounds like you should find better candidates....

floppydisk 10 years ago |

Lets look at it from an evolution of technology angle.

10-15 years ago we had pain points with web apps and making them more fully featured/responsive and dealing with things breaking at scale. They were kind of clunky to build so, we did what all good engineers do and figured out how to make things easier to use for everyone. Now a days, the "kids" are learning how to build web apps that don't require a deep level of knowledge about the stack - we've done a fantastic job building out the tooling that abstracts a lot of these concerns away from the "average" developer. They know if I install framework X and use Library Y the two will communicate correctly. I might understand how they communicate, but don't need to know the intricacies at this time.

Technology is always evolving and what you need to know at a deep level is changing. 60s/70s/80s - The size of the program, how it was laid out on disk, disk sectors, memory layout. All that mattered to get the best performance. You needed to understand how the hardware worked intimately.

90s/ early 00s- Managed languages (Java etc.) become more of a thing and you need to understand less about all the gotchas the prior generations faced. The framework and language abstracted a lot of the prior generation's challenges away and increases in hardware capacity reduced the need to layout programs just so on the disk or in RAM.

Early 00s-Present - Hardware kept growing exponentially in terms of capacity and performance, and we started placing more emphasis on building out scalable, fully functioning web applications (thin clients) rather than thick clients running on a desktop. People figured out a lot of these applications were simply wrappers about DATABASE activities and wrote frameworks that made writing the backend for such apps KISS simple. RoR I'm looking at you! This freed up people to focus on the bells and whistles the user interacted with and reduced the need for anyone developer to know the intimate details of how their framework worked.

It's a changing world and the next generation of programmers is always going to be starting at our current level of abstraction, much like we started at our prior generation's and built our way up. Challenges we faced, overcame, and turned into libraries, become the starting assumption for the new kids that they'll build up from.

On the flip side, I gotta ask, what are you looking for? There are so many "full stack" combinations (language, server, SQL/NoSQL database, front end scripting library) now that the odds of finding a person with deep experience using everything you are using, unless you've reduced to the lowest possible common denominator, is low. Are you looking for someone you can train into the position and has enough knowledge not to blow their foot off, or do you want someone who you can plugin ready to go? Your expectations will influence how you're viewing the candidates, your expectations, and your relative measure of disappointment in them.

dudul 10 years ago |

Maybe you should accept that not everybody knows everything. Your questions are nice to impress your geek buddies but do they really help you to deliver quality?

So what they use ORM instead of raw SQL? Your role as interviewer is to figure out if they would be able to learn. I can almost see your ads: 5 years of OOP with design patterns, 5 years of MySQL database, 3 years of API, etc.

How about you try to figure out if they can learn? A few months ago, I interviewed a junior guy. We were looking at a simple code exercise he did before coming in. I asked "Why did you lose a List here?" "I don't know, I needed a collection" "Do you know how List is implemented?" "No". I spend a couple minute explaining about singly-linked Lists, and ask "Now that you know, would you use it again?" "No, cause it's terrible for append operations".

He didn't know, but I explained and he understood alone. Why don't you try to explain and see if they can come to conclusions?

anshumanravi 10 years ago | |

>Your questions are nice to impress your geek buddies but do they really help you to deliver quality?

I do not ask question to impress, it's to identify whether candidate is capable enough to understand problem domain and come up with efficient solution.Please read post, I am okay with learning part, and asked question for which candidate claims him/herself as expert. I have no issue with they use tools (ORM etc) , but if they dont know how tool works before using it, it's not ideal for me.

romanovcode 10 years ago | | |

Compiler also is a tool. Do you disregard people who do not know how compilers work as well?