21–30 of 60 posts
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 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.
Earlier quoted context omitted.
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.
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'…
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.
Think about it.
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.
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.
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.
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'…
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.
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 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.