41–50 of 60 posts
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..
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/
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 disassemb…
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 invol…
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.
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…
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]
Earlier quoted context omitted.
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 invol…
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…
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.
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.
A lot of people think that Scrum means not looking beyond the end of the next sprint.
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…
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 ar…
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, ex…
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…
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.
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.