
What is wrong with new generation of programmers? - anshumanravi
I have been interviewing programmers for last couple of weeks for full stack developer position,And really disappointed with quality of answers I&#x27;ve got so far .<p>I figured out a common trait among almost all whom I interviewed , They seems to know &#x27;What it does&#x27; but dont know what it is or how it does.<p>For example, They do not know what database indexing is or how it works(They know what it does though, improve query performance, wow!)<p>Ask them few intermediate level sql queries to write and they would be like I did it using ORM of framework xyz.<p>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 &#x27;experts&#x27; 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 &#x27;meh, I dont know&#x27;<p>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.<p>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&#x2F;tools and start calling themselves expert.<p>EDIT : Formatting
======
YuriNiyazov
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
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
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.

~~~
ChemicalWarfare
"full stack" is definitely an overloaded term but then again I wouldn't
consider the kinds of questions OP mentions to be something only the experts
would (or should) be able to answer on the basic level.

Things like get vs post, encoding, basic headers (like accept etc) should be
familiar to anyone dealing with the client side development regardless of the
tools/frameworks.

And then on the backend some basic SQL, basic understanding of indexing, FKs,
PKs, maybe simple inner joins is also something that someone doing anything
DB-related on the backend should be familiar with (unless we're talking
someone who is only familiar with nosql dbs) regardless of the
tools/frameworks/orm etc.

------
Delmania
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.

~~~
cyphar
I think that's fine for developers starting out. But once you start writing
software professionally that is for "the enterprise", it's important to
understand the underlying stack. Knowing how your kernel's plumbing of pipes
actually works (for example) is invaluable in certain cases. Knowing how your
framework's black boxes work is very useful when you run into performance
problems or find bugs. Yes, abstractions are good. But the higher you go up
the stack of abstractions, the less you know about what's actually happening
and thus the less you'll be able to do to actually debug it.

EDIT: Sorry, I didn't read the OP. Yeah, his requirements don't make much
sense (unless he can do the whole industry a favour and explain what he means
by "full stack" developer).

~~~
anshumanravi
Hi, Thanks for comment. Personally speaking by "Full stack" developer, I
expect someone who has enough knowledge of client as well as server
technologies so S(h)e could understand (or better anticipate) problems or
challenges usually s(H)e would face while working on it. It's not about
working for "enterprise", even if it's an in-house product I expect a
programmer to know what S(h)e is doing well. If someone do not know what
tool/framework really doing while one using it,I wouldnt consider it ideal.

------
sharemywin
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.

~~~
anshumanravi
Hi, Agree that interview should be less academic, but academic knowledge does
matter. it’s not really about how much candidate can answer , for that
written/technical test is enough, IMHO Personal interview meant to find out
how candidate approaches to solution, And thats when its disappointing when
candidate would say I know what “db indexing” does but do not know how. If one
do not know how, it signifies candidate is not interested( or capable) enough
to know problem and thus if selected chances of him/her writing erroneous code
would be more. .

~~~
r2dnb
I understand where you're coming from, but the thing is asking :

\- What is DB indexing

\- Can you think of any impact when indexing in this situation

\- What are you general thoughts about indexing, can you think of an example
when you used it and how it helped.

Will indeed give you insight into how he approaches problems and his maturity.
But the difference with this and : tell me how indexing works behind the
scenes, is that you focus on what really matters.

With that there is no right or wrong answers, there's just insightful answers.

I do not disagree on the fact that fundamental knowledge is important, but I
disagree on the way you assess it. I disagree on the notion that there is an
equivalence between fundamental knowledge and formal knowledge. One can be
comfortable adding things up without knowing that it is called an addition.

If he does : great, if he doesn't it doesn't matter as long as he has the
insight.

More generally the majority of our knowledge is not formal.

~~~
anshumanravi
> \- What is DB indexing

Yeah I asked exactly same question, And instead of answering what it i,
candidtate told me why they used it.

> \- Can you think of any impact when indexing in this situation

That's Why I want to know if candidate understand what really index does, One
cant tell a realistic answer of this question until S(h)e knows how index
works.

> \- What are you general thoughts about indexing, can you think of an example
> when you used it and how it helped.

Even if one used it in some situation in pastm and it helped, I would consider
it not enough as it could be possible S(h)e used it by reading some
blog/tutorial etc without understanding it fully, it's like ok switch it off
and on, did it work? well forget about it then.

------
aprdm
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
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.

------
nabla9
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](http://www.bls.gov/oes/current/oes151131.htm)

~~~
brianwawok
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!

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

~~~
brianwawok
Hah let me know how it goes ;) Have never got around to it, but after being on
both sides of super frustrating interviews I bet it could give some surprising
results.

------
joeevans1000
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
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
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
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
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
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
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
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
This. "Lean" and "agile" emphasize feedback and iteration over great
engineering. For a large number of apps, that's acceptable.

~~~
dragonwriter
"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.

~~~
bdcravens
Perhaps "complexity" should be used instead of "great engineering". The best
engineered solutions are those that are simple, easy to understand, and
fulfill business needs (profit, time to market, etc) vis-a-vis satisfying the
programmer ego (In saying this, I'm pointing the finger back at myself as one
who really loves to over-engineer)

------
mattkenefick
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
"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
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
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
> 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
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
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](https://sites.google.com/site/steveyegge2/practical-magic) 2:
[https://sites.google.com/site/steveyegge2/age-racecar-
driver](https://sites.google.com/site/steveyegge2/age-racecar-driver)

------
JSeymourATL
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/](http://www.wired.com/2015/04/hire-like-google/)

------
eecks
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
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
Somewhat related to the general discussion I'm reading in the comments:
[https://www.williamghelfi.com/blog/2015/12/26/william-
versus...](https://www.williamghelfi.com/blog/2015/12/26/william-versus-
technical-interviews/)

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

[https://twitter.com/mxcl/status/608682016205344768](https://twitter.com/mxcl/status/608682016205344768)

------
babakkhan
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
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.

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

Think about it.

------
kaendfinger
Sounds like you should find better candidates....

------
floppydisk
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
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
>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
Compiler also is a tool. Do you disregard people who do not know how compilers
work as well?

