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
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.
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.
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.
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.
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]
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).
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
- 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.
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.
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.
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.
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
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!
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.
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.
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.
There seems to be something in the training that tells them it's not cool to implement things themselves, instead only libraries are OK.
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.
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.
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
Edit: The same culture doesn't recognize that "done" implies a certain level of quality.
They do not emphasize feedback and iteration over quality.
I agree so much so I had to double check that I didn't actually write it.
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?
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.
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.
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.
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.
1: https://sites.google.com/site/steveyegge2/practical-magic 2: https://sites.google.com/site/steveyegge2/age-racecar-driver
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 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..
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.
Think about it.
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.
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?
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.
