What is wrong with new generation of programmers? | Hacker News Reader

What is wrong with new generation of programmers?

30 pointsanshumanravi58 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

View on HN

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.

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 :)

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.

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

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

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.

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

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.

"How well do you understand an internal combustion engine?"

He is not hiring drivers; he is hiring mechanics and manufacturing engineers. And yes, they both absolutely need to know how an IC engine works.

Yes, tools are doing their job, yes they will only keep getting better and I want them to keep getting better. But that is no excuse to not know how they work, and what are the tradeoffs of using one over the other. e.g. There are plenty of ORMs for PHP. Why would you use one over the other? If one ORM generates more efficient queries at the cost of some programming discomfort, I'd much rather have you choose that.

By definition, tools solve generic use-cases. i.e. you can get away with tools as long as you're solving simplistic generic problems that have been solved before. But the moment you transcend that boundary and need to do anything custom, especially at scale, you will totally need to know how things work under the hood. You may still end up modifying an existing tool, but you'll only do a good job at it when you understand the insides.

Also, the urge to look under the hood is simply a proxy to curiosity. That is exactly what starts to separate better engineers from mediocre ones.

[About me: http://InterviewKickstart.com]

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.

Sounds like you were one of the interviewees.

I have a job now but I went through the interview process recently. It was actually the opposite. because I didn't have a lot of experience in the newest versions and didn't come off real confident, I got passed on a lot. never mind in the last 3 years I helped deliver a 20m project in language I never used before and in my spare time learned lua to build a mobile app. One of the interviewers comments was "I think he could do the job he's just didn't come off well in the interview." WTF? Didn't even get a chance to do the're little coding challenge.

I totally agree with this comment. The questions he asks sound really old school to me. This interview style seems very academic, you should focus on their technical maturity for the role, and wonder if they'll be productive in a real world scenario (with Google). I find this sort of gotcha questions pointless.

I like to gauge the maturity of candidates, but I make sure to never use gotcha questions. I propose them comfortable real world scenarios, and help them show the best of their thought process.

I've interviewed many people who were very good at answering this kind of theoretical questions but were short on delivery when I proposed them the test project supposed to demonstrate how readily they use these concepts in real world situations.

Quite frankly, it looks like the author has the graduate syndrome : http://read.reddy.today/read/10/the-graduate-syndrome

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

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.

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

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.

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.

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.

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

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!

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

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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

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

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)

That's how it usually works out though. I always get in trouble with management when I try to anticipate things we will probably need in 6 months before making design decisions.

A lot of people think that Scrum means not looking beyond the end of the next sprint.

It's also a culture of no training.

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.

"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?

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.

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.

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

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.

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

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/

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

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.

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

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

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

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.

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.

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.

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

Think about it.

Sounds like you should find better candidates....

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.

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?

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

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

Reply on news.ycombinator.com