What not to ask technical people in interviews(fusioncube.net)
fusioncube.net
What not to ask technical people in interviews
http://www.fusioncube.net/index.php/what-not-to-ask-technical-people-in-interviews
14 comments
> Good luck developing anything mission critical with a team of low paid googlers.
IMHO, that's another dark-secret of this trade, most of us don't develop "mission critical" services. By "mission critical" I understand something like "if this code breaks then someone dies or huge sums of money are lost etc.".
> One day even people in our profession might come to actually have some self-respect for what we do
I totally agree with you that "software development is hard", but not because someone happens not to know what methods a standard library class implements (every few days I give almost god-like thanks to the developer that decided to implement the dir() function in Python), but because ~35 years after "The Mythical Man-Month" was first published we repeat at least half of the mistakes presented in there.
IMHO, that's another dark-secret of this trade, most of us don't develop "mission critical" services. By "mission critical" I understand something like "if this code breaks then someone dies or huge sums of money are lost etc.".
> One day even people in our profession might come to actually have some self-respect for what we do
I totally agree with you that "software development is hard", but not because someone happens not to know what methods a standard library class implements (every few days I give almost god-like thanks to the developer that decided to implement the dir() function in Python), but because ~35 years after "The Mythical Man-Month" was first published we repeat at least half of the mistakes presented in there.
Yup, I agree.
Software engineering also requires a lot of mental pain, and struggling and debugging, but the end result? it's equal to what other occupations produce with less struggle.
Software engineering also requires a lot of mental pain, and struggling and debugging, but the end result? it's equal to what other occupations produce with less struggle.
And it's never the same half of the mistakes, is it? :(
That's the thing that annoys me about software engineering--it's impressive that it works at all, and that isn't a good sort of impressed.
That's the thing that annoys me about software engineering--it's impressive that it works at all, and that isn't a good sort of impressed.
"Good luck developing anything mission critical with a team of low paid googlers."
This is the dirty secret of outsourcing.
This is the dirty secret of outsourcing.
And the dirty secret of outsourcing is that it very rarely goes the way people want it to go and the low paid googlers end up being replaced by very expensive experienced software developers.
Sorry, that's what I was implying. You get a bunch of people who work for so cheap because they're not properly trained, they invade forums and such asking for "the codez". The product can end up as a bunch of code snippets pasted in from the Internet, may work, may not.
http://plzsendmethecode.blogspot.com/
http://plzsendmethecode.blogspot.com/
If your original team was a bunch of improperly trained people who happen to be nearer to you geographically, at the very least, you have saved some money building a product which, as you say, may or may not work.
Here, let's grep and replace:
"The dirty little secret that I don’t mind saying is that mechanical engineering isn’t hard. There’s lots of handbooks, manuals, blog entries and Stack Overflow Q&A pages out there that very clearly describe how to work with any stress equation or tool. Follow it step by step and you are a mechanical engineer."
This is pretty common in professional engineering--most bridge/pressure vessel/structural engineering is done by effectively filling in the blanks on worksheets and following thick handbooks of best practices. Are they too worth your contempt?
Self-respect doesn't enter into it--computer science might be hard, mathematics might be hard, clever low-level or very abstract programming might be hard...but software development? Especially as practiced nowadays with the toolsets and parts we are encouraged (nay, expected!) to use?
No, software development need not be any harder than any other form of white-collar engineering.
"The dirty little secret that I don’t mind saying is that mechanical engineering isn’t hard. There’s lots of handbooks, manuals, blog entries and Stack Overflow Q&A pages out there that very clearly describe how to work with any stress equation or tool. Follow it step by step and you are a mechanical engineer."
This is pretty common in professional engineering--most bridge/pressure vessel/structural engineering is done by effectively filling in the blanks on worksheets and following thick handbooks of best practices. Are they too worth your contempt?
Self-respect doesn't enter into it--computer science might be hard, mathematics might be hard, clever low-level or very abstract programming might be hard...but software development? Especially as practiced nowadays with the toolsets and parts we are encouraged (nay, expected!) to use?
No, software development need not be any harder than any other form of white-collar engineering.
It isn't that much different from other forms of engineering. And in all of those forms, there are the "formula plugger" engineers, and there are the real engineers.
The difference was exemplified by a question another "engineer" asked me once - "what book did you get that formula from?" I replied that I derived it from the boundary conditions, etc. He just looked at me in utter bafflement.
On a related note, it's easy to discover the "formula pluggers" in electrical engineering. They are the ones that carry around a little card with:
The difference was exemplified by a question another "engineer" asked me once - "what book did you get that formula from?" I replied that I derived it from the boundary conditions, etc. He just looked at me in utter bafflement.
On a related note, it's easy to discover the "formula pluggers" in electrical engineering. They are the ones that carry around a little card with:
V=IR
I=V/R
R=V/I
Show them the PIRE wheel, it will blow their minds: http://www.google.com/search?q=pire+wheel&hl=en&prmd...
The problem here is that in things like chemical or structural engineering, you generally don't just bodge together things by first principles.
In fact, there is a great deal of liability on the line--so much so, for example, that the guild (for what else is something like the ASME, really?) has decided "Here are the equations by which we design pressure vessels. Plug in your material--from this table of guaranteed grades and empirical data--and your dimensions, and lo, here's what you should spec."
As wonderful as it is to derive these things from equations and first principles, and as satisfying as it is to do so, do you really want to stake your career on your own from-scratch solution to a CFD problem? Or on the exact solver that you used to solve those PDEs? Or on your "hunch" as for which forces were truly at play?
Or do you want to follow the guidelines in Shigley's, Roark's, ASME codebooks, NACA airfoil reference, etc., and be able to more easily pass through a forensic engineering post-mortem?
Electrical engineering and computer science may not have had the same checkered history as some of the more established disciplines, but that doesn't mean you can't learn something from their rigor.
In fact, there is a great deal of liability on the line--so much so, for example, that the guild (for what else is something like the ASME, really?) has decided "Here are the equations by which we design pressure vessels. Plug in your material--from this table of guaranteed grades and empirical data--and your dimensions, and lo, here's what you should spec."
As wonderful as it is to derive these things from equations and first principles, and as satisfying as it is to do so, do you really want to stake your career on your own from-scratch solution to a CFD problem? Or on the exact solver that you used to solve those PDEs? Or on your "hunch" as for which forces were truly at play?
Or do you want to follow the guidelines in Shigley's, Roark's, ASME codebooks, NACA airfoil reference, etc., and be able to more easily pass through a forensic engineering post-mortem?
Electrical engineering and computer science may not have had the same checkered history as some of the more established disciplines, but that doesn't mean you can't learn something from their rigor.
>The problem here is that in things like chemical or structural engineering, you generally don't just bodge together things by first principles.
The thing is, formula pluggers are unable to put formulas together from first principles because they simply do not understand them. All the book formulas are based on certain assumptions - and so the formulas will give you wrong results if your real world problem doesn't match those assumptions.
When it doesn't match the book formula assumptions, you have to derive one that does. And that requires understanding. Furthermore, you check your equations backwards and forwards using well known techniques. Lastly, you back up your analytical results by using a test rig.
Yes, I've known a lot of formula pluggers. You argue that they get rigorous correct answers. They don't, they misuse the formulas because they fail to understand them.
Understanding that is what separates a real engineer from a formula plugging technician.
The thing is, formula pluggers are unable to put formulas together from first principles because they simply do not understand them. All the book formulas are based on certain assumptions - and so the formulas will give you wrong results if your real world problem doesn't match those assumptions.
When it doesn't match the book formula assumptions, you have to derive one that does. And that requires understanding. Furthermore, you check your equations backwards and forwards using well known techniques. Lastly, you back up your analytical results by using a test rig.
Yes, I've known a lot of formula pluggers. You argue that they get rigorous correct answers. They don't, they misuse the formulas because they fail to understand them.
Understanding that is what separates a real engineer from a formula plugging technician.
What impact does this make on actual work delivered?
Seriously, we can talk about negligible leaps of quality that a guy who learns things in details has over the one who works with powerful layers of abstractions.
There a lot of workshop guys and foremen, who can repair even the most difficult problems in car engines without understand much about the physics and chemistry of things going on inside an engines. They can also build custom engines by assembling parts. Sure they can't match quality of a guy who can build everything from scratch, but get enough quality of build useful things. A lot of them can build homes.
Surely some centuries back only mechanical and civil engineers could do this. But today we have tools and techniques that make dealing with things very easy.
This is the natural graph of evolution in every discipline. Not just software but in nearly everything.
Seriously, we can talk about negligible leaps of quality that a guy who learns things in details has over the one who works with powerful layers of abstractions.
There a lot of workshop guys and foremen, who can repair even the most difficult problems in car engines without understand much about the physics and chemistry of things going on inside an engines. They can also build custom engines by assembling parts. Sure they can't match quality of a guy who can build everything from scratch, but get enough quality of build useful things. A lot of them can build homes.
Surely some centuries back only mechanical and civil engineers could do this. But today we have tools and techniques that make dealing with things very easy.
This is the natural graph of evolution in every discipline. Not just software but in nearly everything.
I worked on airplane design. Getting the design light and strong was worth $$$$. The extra money to pay a real engineer was nothing compared with the cost of keeping heavy objects at 30,000 feet. In electronics, shaving cost off a design you're going to make millions of copies of is worth $$$$.
Repairing a car engine is very different from designing one. There's a reason why, if you want to work on race cars on a professional team, they expect you to have an engineering degree and use it.
Designing a house isn't much engineering. There you can easily afford to way, way overbuild it to compensate for utter lack of finesse. (Funny story - in Florida they found that Habitat for Humanity houses stood up to hurricanes better. The reason? Habitat workers knew nothing about construction, and so used far too many nails.)
You're right that any semi-competent mechanic can build a working tractor from scratch, with doing no calculations at all. But it'll be either excessively heavy, or not strong enough, or cost far too much to build.
I'm not saying you should re-derive book formulas. But you are often going to encounter problems that don't have book solutions - like calculating the moment of inertia of a spinning part that doesn't match the shape of the book formulas. Or the bending strength of a beam with an unusual cross section. Then, you gotta know how those book formulas are derived in order to derive the right formula for your unusual shape.
Your alternative is to overdesign, or to compromise your design into being book shapes. Have you ever noticed that your car doesn't contain many parts with book shapes?
Repairing a car engine is very different from designing one. There's a reason why, if you want to work on race cars on a professional team, they expect you to have an engineering degree and use it.
Designing a house isn't much engineering. There you can easily afford to way, way overbuild it to compensate for utter lack of finesse. (Funny story - in Florida they found that Habitat for Humanity houses stood up to hurricanes better. The reason? Habitat workers knew nothing about construction, and so used far too many nails.)
You're right that any semi-competent mechanic can build a working tractor from scratch, with doing no calculations at all. But it'll be either excessively heavy, or not strong enough, or cost far too much to build.
I'm not saying you should re-derive book formulas. But you are often going to encounter problems that don't have book solutions - like calculating the moment of inertia of a spinning part that doesn't match the shape of the book formulas. Or the bending strength of a beam with an unusual cross section. Then, you gotta know how those book formulas are derived in order to derive the right formula for your unusual shape.
Your alternative is to overdesign, or to compromise your design into being book shapes. Have you ever noticed that your car doesn't contain many parts with book shapes?
Exceptions only prove the rule.
The number of people working on mission critical stuff are always going to be lesser.
I am not against learning things in detail. I am only saying these days productivity has become more important metric than them in most general cases.
Now please don't tell me about cases like space craft/airplane design. You and I know well, they don't apply to the masses.
And after all experts have got to be good at something.
The number of people working on mission critical stuff are always going to be lesser.
I am not against learning things in detail. I am only saying these days productivity has become more important metric than them in most general cases.
Now please don't tell me about cases like space craft/airplane design. You and I know well, they don't apply to the masses.
And after all experts have got to be good at something.
Heh, when I was in my Electrical Engineering programme, I got funny looks; instead of the formulas listed, I pretty much had to just keep two straight: i = C dv/dt and v = L di/dt. Alternatively, Z = 1/Cs and Z = Ls. While everyone else was trying to keep all of their formulae with exponentials straight, I'd just solve from the base equations (either by solving the diff-eqs or equivalently the inverse Laplace transform).
So what is going to happen when you are asked to design (or dare I say "engineer") a system of some sort from scratch? Say, an engine or a component of an engine or a complete new machine? That is engineering. What you described sounds like the duties of a technician or a mechanic. That is not engineering.
Firstly:
A designer is allowed to come up with whatever they want.
An engineer is subject to constraints, most notably: does it work, is it safe, and is it cheap. That last value does not always mean money--what is the cost if the design goes wrong, or if others have to maintain it, and so forth.
This is the popular notion of "engineering": that a stoic engineer sits down, sliderule or vim in the one hand and coffeepot in the other, and sits up into the wee hours of the night scrawling schematics onto a sheet of paper or typing into a VT101, only to go pound rivets or machine code the following morning with only the aid of his throbbing turgid member--this is absurd!
Secondly:
In your case, for an engine, I would ask for details about the weight, cost, power output, speed, time, maintenance lifecycle, and predicted loadings of the engine. Then, I would sit down and blackbox the inputs and outputs. Then, I would go and figure out mechanisms to accomplish each box. Then, I would look up the values for those materials--honestly, do you expect me to come up with the vibration amplitude of a forged 316 stainless shaft of x length and y rpm myself? You don't want me to not use tables for that! Those things--the "engineering"--done, I'd get to the actual "design" work: how do I shape these mechanisms, how do I get them to fit in a box in the size we decided on, etc.
To hold you to your own standard:
Would you write your own web stack?
Okay, would you write your own protocol?
Your own compiler?
Linker?
OS?
Hardware?
We stand on the shoulders of giants--I am no less an engineer for using reference tables and formula than you are for using Redis/Rails/libc/Ruby/Python/etc.
The lack of invention? That's the sign of maturity.
A designer is allowed to come up with whatever they want.
An engineer is subject to constraints, most notably: does it work, is it safe, and is it cheap. That last value does not always mean money--what is the cost if the design goes wrong, or if others have to maintain it, and so forth.
This is the popular notion of "engineering": that a stoic engineer sits down, sliderule or vim in the one hand and coffeepot in the other, and sits up into the wee hours of the night scrawling schematics onto a sheet of paper or typing into a VT101, only to go pound rivets or machine code the following morning with only the aid of his throbbing turgid member--this is absurd!
Secondly:
In your case, for an engine, I would ask for details about the weight, cost, power output, speed, time, maintenance lifecycle, and predicted loadings of the engine. Then, I would sit down and blackbox the inputs and outputs. Then, I would go and figure out mechanisms to accomplish each box. Then, I would look up the values for those materials--honestly, do you expect me to come up with the vibration amplitude of a forged 316 stainless shaft of x length and y rpm myself? You don't want me to not use tables for that! Those things--the "engineering"--done, I'd get to the actual "design" work: how do I shape these mechanisms, how do I get them to fit in a box in the size we decided on, etc.
To hold you to your own standard:
Would you write your own web stack?
Okay, would you write your own protocol?
Your own compiler?
Linker?
OS?
Hardware?
We stand on the shoulders of giants--I am no less an engineer for using reference tables and formula than you are for using Redis/Rails/libc/Ruby/Python/etc.
The lack of invention? That's the sign of maturity.
I have done all of these things, and I know when it's appropriate and when it's not. The trick isn't that I can "come up with the vibration amplitude of a forged 316 stainless shaft", but that I know how I could do that. Over and over, I've seen the effects of failing to understand the abstractions (formula tables) that people are using to develop software. It's that fundamental base understanding that, in my opinion, can propel someone from pretty good to exceptionally awesome.
[deleted]
"low paid googlers" is an interesting phrase. Took me a moment to get it, and disambiguate from "high-paid Googlers"
We, with our very hands destroyed this when we started inventing IDE's that had intelligence to do nearly everything that had to be learn't to be done other wise.
We invented frameworks to cover large number of solutions to problems.
Its something like this. There was a point of time among mechanical engineers when knowing how to assemble and sweating it making things in the workshop was glorious. Today most of those jobs are inevitably automated. And apart from design and actual engineering. Most mechanical engineers can be clearly separated from foremen and workshop guys.
The same is happening with software, IDE's and frameworks are making it damn easy for any idiot with vague ideas to program things into existence. Soon coding in itself will not be a very task in itself.
At this rate its scary to imagine how future generation of programmers will even program. They may just deal with visual interfaces which generate programs in the backend.
This is sad but inevitable in every discipline of engineering.
We invented frameworks to cover large number of solutions to problems.
Its something like this. There was a point of time among mechanical engineers when knowing how to assemble and sweating it making things in the workshop was glorious. Today most of those jobs are inevitably automated. And apart from design and actual engineering. Most mechanical engineers can be clearly separated from foremen and workshop guys.
The same is happening with software, IDE's and frameworks are making it damn easy for any idiot with vague ideas to program things into existence. Soon coding in itself will not be a very task in itself.
At this rate its scary to imagine how future generation of programmers will even program. They may just deal with visual interfaces which generate programs in the backend.
This is sad but inevitable in every discipline of engineering.
If any average Joe can make something that works, then the true and valuable skill is to make something that is simple, understandable, and maintainable.
I don't think modern tools help you with any of the constant decisions needed to hit those marks.
I don't think modern tools help you with any of the constant decisions needed to hit those marks.
I never implied that.
What I said was over the years with the help of tools it takes lesser intellectual work because the more and more skill based intelligent work is automated inside IDE's and frameworks.
You can do a lot of network programming today without actually understand anything about networks. You could not have said the same around 15-20 years back.
What I said was over the years with the help of tools it takes lesser intellectual work because the more and more skill based intelligent work is automated inside IDE's and frameworks.
You can do a lot of network programming today without actually understand anything about networks. You could not have said the same around 15-20 years back.
Wow, that is quite an article. I think it manages the rare feat of being completely wrong. Usually people write enough words that they stumble into saying something useful.
Personally, I love asking esoteric questions in interviews, but not because I care about that particular question. I am trying to figure out if you are the kind of programmer who looks beneath the covers to figure out what is really going on. Do I expect every programming to know how b-trees relate to database indexes, and what their lookup times are, no. But if you have written a lot of SQL and never bothered to figure that out, you are probably a slave to the SQL interface and aren't the type of person who will ever really understand how to optimize queries. The point is to figure out they type of person they are.
Secondarily, I like working with nice people. It's important. But I have worked with nice and smart people who wrote horrible unmaintainable code, and I ended up loathing working with them. Plus, the better the programmers, the less of them you need. Turns out this is terribly important in software.
Personally, I love asking esoteric questions in interviews, but not because I care about that particular question. I am trying to figure out if you are the kind of programmer who looks beneath the covers to figure out what is really going on. Do I expect every programming to know how b-trees relate to database indexes, and what their lookup times are, no. But if you have written a lot of SQL and never bothered to figure that out, you are probably a slave to the SQL interface and aren't the type of person who will ever really understand how to optimize queries. The point is to figure out they type of person they are.
Secondarily, I like working with nice people. It's important. But I have worked with nice and smart people who wrote horrible unmaintainable code, and I ended up loathing working with them. Plus, the better the programmers, the less of them you need. Turns out this is terribly important in software.
I think, though, that it's wrong to decide "this person is not intellectually curious" merely because he has never investigated the particular esoteric bit you picked to test "intellectual curiosity".
I could ask you if you know the x86 calling conventions--what, you don't know? But you use x86 machines every day, and write code to run on x86! You're obviously a slave to Ruby/C++/<insert-language-here> and just aren't the type of guy to go learn things.
I could ask you if you know the x86 calling conventions--what, you don't know? But you use x86 machines every day, and write code to run on x86! You're obviously a slave to Ruby/C++/<insert-language-here> and just aren't the type of guy to go learn things.
Like I said, I'm not trying to find out if you know a particular thing, I'm trying to figure out if you ever learn things that are deeper than the surface. So, if you don't know x86 calling conventions, fine. But if I ask several more questions in that domain, and you don't know any of them, then I check your resume and you having been writing C level code for years, I'm concerned.
Actually, I'd say the #1 thing not to ask me in an interview is "What is your passion?".
Did you really want to hear about my time between the sheets with my wife? No.
Did you really want to hear about my love of outdoor Humans vs Zombies games, or the different kinds of Munchkin games? No.
You probably wanted to hear about my work as a hobbyist Computer Science researcher, but I don't want to tell you about that. You would understand half of it and then decide that I'm a grad-school egghead who doesn't belong at your company.
Luckily, I applied to graduate school this year.
Did you really want to hear about my time between the sheets with my wife? No.
Did you really want to hear about my love of outdoor Humans vs Zombies games, or the different kinds of Munchkin games? No.
You probably wanted to hear about my work as a hobbyist Computer Science researcher, but I don't want to tell you about that. You would understand half of it and then decide that I'm a grad-school egghead who doesn't belong at your company.
Luckily, I applied to graduate school this year.
In other words, you will do what 99% of all applicants will do, even the ones that didn't really want the job in the first place: you'll tell the interviewer what you think they want to hear.
The lesson here is: "asking questions" does not equal "having a conversation". No amount of lists, short or long, will result in a good job interview.
The lesson here is: "asking questions" does not equal "having a conversation". No amount of lists, short or long, will result in a good job interview.
>In other words, you will do what 99% of all applicants will do, even the ones that didn't really want the job in the first place: you'll tell the interviewer what you think they want to hear.
Well no, I tend to do the Luciferian thing: tell the complete truth and let them hear what they please.
This has, in its time, lost me a couple of opportunities because they didn't want someone who was aiming for research rather than aiming for their position. Of course, those opportunities were in entry-level software engineering positions.
Well no, I tend to do the Luciferian thing: tell the complete truth and let them hear what they please.
This has, in its time, lost me a couple of opportunities because they didn't want someone who was aiming for research rather than aiming for their position. Of course, those opportunities were in entry-level software engineering positions.
The people who ask what your passion is and are looking to hear that you program for the heck of it are simply trying to cash in. Likely you'll be willing to work longer hours and get paid less then your knowledge is worth because you'll get to work on "exciting and challenging stuff!".
I've met several people who think this is the only way to hire "real" programmers. They never get it when I point out that no other profession operates in this manner.
I've met several people who think this is the only way to hire "real" programmers. They never get it when I point out that no other profession operates in this manner.
What these same people also fail to realize is that just because you enjoy working on "exciting and challenging stuff!" doesn't mean you will find debugging their firm's spaghetti code exciting.
Yes, there are projects on which I would work 10-15 hours a day with minimal pay but, odds are - yours isn't one of them.
Yes, there are projects on which I would work 10-15 hours a day with minimal pay but, odds are - yours isn't one of them.
Bitterness is extremely easy to detect and is one of thered flag culture-fit no-hire reasons at my office.
Passion is passion. Bad pay is bad pay. They are orthogonal.
Passion is passion. Bad pay is bad pay. They are orthogonal.
Did you really want to hear about my love of outdoor Humans vs Zombies games
My personal experience as an interviewer: there is a very high correlation between people who are really into something and people who are good hires. Ideally something that requires some suffering to do well (e.g. sports) but what I'm looking for is that whatever it is, they feel strongly enough about it to pursue it doggedly for years at a time.
My personal experience as an interviewer: there is a very high correlation between people who are really into something and people who are good hires. Ideally something that requires some suffering to do well (e.g. sports) but what I'm looking for is that whatever it is, they feel strongly enough about it to pursue it doggedly for years at a time.
The questions proposed in the article seem to be optimized to produce the most bullshit responses.
Some of us are looking for grad school eggheads, and pay a lot for it.
tl;dr; I only ask detailed questions about technologies of which a candidate claims recent and deep knowledge. Wrong answers suggest stupidity or dishonesty.
Let's say I'm interviewing someone who claims to have been a professional software for a decade and that most of his work was in Java. I know Java quite well, and I know what sorts of things one HAS to know about Java if he doesn't fundamentally suck as a software developer and isn't lying on his resume. If you claim to have written Java code for the past five years but can't explain the difference between a Set and a List, you are either stupid or dishonest. One of my favorite questions for a supposedly experienced Java developer is to show them a code snippet with a try/catch block and ask them to trace through the code's execution in both the case where an exception was thrown and the "happy path". Roughly 40% of the people I've interviewed who have claimed years of recent Java experience (like they were coding in Java the day before) think that a method's execution terminates when a catch block is entered and that block's code finishes executing! How could one possibly write correct code without understand this? How much evidence to the contrary must they have ignored? One developer complained to me that my question was hard because he was "mostly used to dealing with SqlException and not other exception types." He then complained that he was an experienced Java developer and didn't see how my question was relevant to the job for which he was interviewing. Want him on your team?
Let's say I'm interviewing someone who claims to have been a professional software for a decade and that most of his work was in Java. I know Java quite well, and I know what sorts of things one HAS to know about Java if he doesn't fundamentally suck as a software developer and isn't lying on his resume. If you claim to have written Java code for the past five years but can't explain the difference between a Set and a List, you are either stupid or dishonest. One of my favorite questions for a supposedly experienced Java developer is to show them a code snippet with a try/catch block and ask them to trace through the code's execution in both the case where an exception was thrown and the "happy path". Roughly 40% of the people I've interviewed who have claimed years of recent Java experience (like they were coding in Java the day before) think that a method's execution terminates when a catch block is entered and that block's code finishes executing! How could one possibly write correct code without understand this? How much evidence to the contrary must they have ignored? One developer complained to me that my question was hard because he was "mostly used to dealing with SqlException and not other exception types." He then complained that he was an experienced Java developer and didn't see how my question was relevant to the job for which he was interviewing. Want him on your team?
Aha,
Here is the problem. The days of deep reading and understand and learning are behind us. IDE's really know what is good for what situation and just autocomplete whatever is appropriate. The days when you had to read the manual at every unknown point and besides text based autocompletion in Emacs/Vi no other help from IDE's are long behind us.
Most programmers todays are all about such things. In other words and putting it very directly. Productivity has become an order of an magnitude more important than knowledge and intelligence.
That is partly also because a lot of work needs to be done today than it was a decade back. And when the ecosystem grows at such a rate tools to enable the common folks program get invented.
These days its all about productivity.
EDIT : Downvote this as much as you like, but more the frameworks and more the intelligent IDE's get. Lesser and lesser significant our jobs become.
In fact to an extent they already have.
Here is the problem. The days of deep reading and understand and learning are behind us. IDE's really know what is good for what situation and just autocomplete whatever is appropriate. The days when you had to read the manual at every unknown point and besides text based autocompletion in Emacs/Vi no other help from IDE's are long behind us.
Most programmers todays are all about such things. In other words and putting it very directly. Productivity has become an order of an magnitude more important than knowledge and intelligence.
That is partly also because a lot of work needs to be done today than it was a decade back. And when the ecosystem grows at such a rate tools to enable the common folks program get invented.
These days its all about productivity.
EDIT : Downvote this as much as you like, but more the frameworks and more the intelligent IDE's get. Lesser and lesser significant our jobs become.
In fact to an extent they already have.
>IDE's really know what is good for what situation
>and just autocomplete whatever is appropriate.
If people claim to be doing something everyday which requires detailed knowledge of X, they ought to be able to tell me about X. An IDE can't know if a List or Set is more appropriate. To know this, it would have to know my intent. I agree that higher-level abstractions (declarative statements implying the need for one over the other, etc.) might be in our future, but the people I'm interviewing claim to be writing Java. I don't expect a Java developer to know any particular processor's instruction set, but I sure would expect, say, a person who recently wrote an x86 assembler to have detailed knowledge in this area.
If people claim to be doing something everyday which requires detailed knowledge of X, they ought to be able to tell me about X. An IDE can't know if a List or Set is more appropriate. To know this, it would have to know my intent. I agree that higher-level abstractions (declarative statements implying the need for one over the other, etc.) might be in our future, but the people I'm interviewing claim to be writing Java. I don't expect a Java developer to know any particular processor's instruction set, but I sure would expect, say, a person who recently wrote an x86 assembler to have detailed knowledge in this area.
The more my IDE does, the more I am expected to do above and beyond what the IDE does.
The areas above and higher your IDE are/will be little to do with math and bit shifting.
They will be more and more of domain knowledge and understanding the problem on hand and little and little to do with worrying and learning arcane facts behind the scenes.
Some applications may need it but most won't.
They will be more and more of domain knowledge and understanding the problem on hand and little and little to do with worrying and learning arcane facts behind the scenes.
Some applications may need it but most won't.
How do you figure that knowing the execution path for a basic language feature is an "arcane fact behind the scene?" This is equivalent to not knowing how an if or for statement works. You can't write ANY code without this knowledge.
How were we able to understand try/catch while all we had known is return statements from functions and error checking through flags?
How were we able to understand if/else statements now, while all we were able to understand jmp and goto statements earlier.
How can people work with Microsoft excel without actually knowing they are into databases and functional programming?
First you learn how to use a logical block of programming, then you learn many other blocks. Then you learn how to use them together. Then many interacting blocks come as a pre packaged solution to a lot of problems. Assembling those blocks comes in the forms of of IDE's. That is how we have managed to move from bits, to assembly language programming, to languages lisp, C and till now where IDE's do most of what we do.
If you had asked anybody 50 years back if we could have come this far. Their answer would be no. Same as many people today can't believe that programming can be done without actually writing code syntactically.
You can do a lot of network programming today or IO programming today without knowing anything about OS or deeper networking aspects. You could not have told the same thing 15-20 years back. The average skill required to achieve these tasks is only decreasing.
On an average scale the skills, knowledge and work required to be a good programmer over 50 years has only decreased.
In the future, the solution to a problem doesn't necessarily has to be a code.
Haven't we seen Yahoo Pipes and things like that?
I can understand this attitude that most people are showing, because it effects their bread and butter. But this is the natural progression in any discipline.
I doesn't take an army of farmers and cows to do farming today. Farming is far more productive today than it was 100 years back.
The same case will be with software. Like it or not, it is going to happen.
How were we able to understand if/else statements now, while all we were able to understand jmp and goto statements earlier.
How can people work with Microsoft excel without actually knowing they are into databases and functional programming?
First you learn how to use a logical block of programming, then you learn many other blocks. Then you learn how to use them together. Then many interacting blocks come as a pre packaged solution to a lot of problems. Assembling those blocks comes in the forms of of IDE's. That is how we have managed to move from bits, to assembly language programming, to languages lisp, C and till now where IDE's do most of what we do.
If you had asked anybody 50 years back if we could have come this far. Their answer would be no. Same as many people today can't believe that programming can be done without actually writing code syntactically.
You can do a lot of network programming today or IO programming today without knowing anything about OS or deeper networking aspects. You could not have told the same thing 15-20 years back. The average skill required to achieve these tasks is only decreasing.
On an average scale the skills, knowledge and work required to be a good programmer over 50 years has only decreased.
In the future, the solution to a problem doesn't necessarily has to be a code.
Haven't we seen Yahoo Pipes and things like that?
I can understand this attitude that most people are showing, because it effects their bread and butter. But this is the natural progression in any discipline.
I doesn't take an army of farmers and cows to do farming today. Farming is far more productive today than it was 100 years back.
The same case will be with software. Like it or not, it is going to happen.
I've developed a simple set of questions to avoid these types of pointless interviews.
It was last tested about two weeks ago when I was casually talking with the founder of a local startup who wanted me to join his team. I politely declined the offer.
Here are the questions:
1. What is your product?
If the answer to this is marketing talk, they fail the test.
2. Who is your customer?
Same with #1, but add "everybody!".
3. What is your development setup/rules/guidelines?
No source control? Bye.
Testing on production servers? Bye (this startup did that, and wondered why their app failed to work).
No workstations? You mean that I will use my personal computer at your office? Bye, Bye!
What language/framework/technology do you use? If the answer is PHP/in house MVC then I'm out. I dont mind PHP/MVC, but most are hacked up pieces of crap that can't compare to symfony or even code igniter/cakephp.
This allows me to consider working with people who know what they are doing, instead of wasting time with people who want to test me on what they think I know.
This simple test was developed after an interview with a local startup. The interviewer was the "software engineer", and he had pulled questions from project euler to test me. After realizing this, I ended the interview quickly. Their product? A web app for realtors to showcase their listings. Yeah, that required developers that were able to solve advanced project euler exercises.
It was last tested about two weeks ago when I was casually talking with the founder of a local startup who wanted me to join his team. I politely declined the offer.
Here are the questions:
1. What is your product?
If the answer to this is marketing talk, they fail the test.
2. Who is your customer?
Same with #1, but add "everybody!".
3. What is your development setup/rules/guidelines?
No source control? Bye.
Testing on production servers? Bye (this startup did that, and wondered why their app failed to work).
No workstations? You mean that I will use my personal computer at your office? Bye, Bye!
What language/framework/technology do you use? If the answer is PHP/in house MVC then I'm out. I dont mind PHP/MVC, but most are hacked up pieces of crap that can't compare to symfony or even code igniter/cakephp.
This allows me to consider working with people who know what they are doing, instead of wasting time with people who want to test me on what they think I know.
This simple test was developed after an interview with a local startup. The interviewer was the "software engineer", and he had pulled questions from project euler to test me. After realizing this, I ended the interview quickly. Their product? A web app for realtors to showcase their listings. Yeah, that required developers that were able to solve advanced project euler exercises.
It's hard for me to believe there exist companies that have the resources to hire software developers and that don't use source control.
You better start believing it, I've seen it... If you doubt my anecdata, check TheDailyWTF.
It seems to me that the problem is too many people see software development as linear and quality as monotonically increasing, i.e. just save your work and back it up.
It seems to me that the problem is too many people see software development as linear and quality as monotonically increasing, i.e. just save your work and back it up.
I was being tag-team interviewed for a programming job. The first guy asked me what I disliked about my current workplace. I said, "Nothing," because money was my only reason for leaving. He didn't believe I couldn't find one negative thing to say, and made bold marks (probably a big "X") on a paper. In the next interview, a lady manager asked me the same question. Not wanting to make the same mistake twice, I said, "Office politics," and sat back smiling, ready for the next question. She frowned and said, "Define office politics." I said, "Umm..habbadababbadah...gah..er," until she decided to move on to another question. I got the job!
Start asking me about B-tree algorithms and my eyes will glaze over.
However you can go and look inside my MySQL database tables and you will see a beautiful relational database. I enjoy computers/programming because going back as far as I can remember I have never run across a problem that I could not figure out with enough gray matter time. I really enjoy making stuff and solving problems, I used to do all of my math homework in my head and then have to go back and write out the solutions (for the teacher to check) just because I enjoyed solving the problem step by step.
TLDR: I build stuff, it works and I smile.
TLDR: I build stuff, it works and I smile.
Not that I don't believe you, but I'm genuinely curious.
When you're designing a "beautiful relational database" without thinking about the algorithms behind it, how are you taking the performance effects of those algorithms into account? How do you know which relationships and queries are likely to be efficient and which are not?
When you're designing a "beautiful relational database" without thinking about the algorithms behind it, how are you taking the performance effects of those algorithms into account? How do you know which relationships and queries are likely to be efficient and which are not?
Parent is talking about beautiful schema, not a beautiful query planner. If you are capable of understanding the concept of abstraction and encapsulation, you can design a good system knowing the performance characteristics of your components but not their internals.
The geniuses who wrote postgres don't know how to write responsive web sites. The geniuses who make gorgeous fast websites don't know how a Btree is implemented. It's OK. That's how the global economy works.
The geniuses who wrote postgres don't know how to write responsive web sites. The geniuses who make gorgeous fast websites don't know how a Btree is implemented. It's OK. That's how the global economy works.
But the fast-website people still need to know what makes a query slow and how to improve it. They don't (and shouldn't) write their own database engine, but they need to know how their equipment works.
That's what I'm getting at though; a schema that is "beautiful" but performs terribly isn't all that beautiful in my eyes.
What I was trying to get across is that knowing the correct term for something and actually knowing how to do it are two different things. I run across stuff all the time in CS where I'm like huh? what's that? then I google it and find out "oh so that's what you call the way that I did "X" in "Y" application.
The deeper problem is that job interviews are irremediably broken. They are artificial to the point of stupidity. At least for the kind of work we do in software, there is no fixing them. They need to be thrown out and replaced with something else.
Working together is a kind of relationship. You don't interview for a relationship.
Working together is a kind of relationship. You don't interview for a relationship.
Sure you do - it's called a date.
After an interview/date, you then have (in the UK at least) a probationary period (going steady), and then a wait before a statutory period (engagement) before you are fully "employed" in law and can't be removed easily (marriage).
After an interview/date, you then have (in the UK at least) a probationary period (going steady), and then a wait before a statutory period (engagement) before you are fully "employed" in law and can't be removed easily (marriage).
Your analogy confirms my point, because the things that make job interviews so awful are not things people do on dates - not without being crushingly inappropriate. What you're talking about, it seems to me, is contactful conversation. That's precisely what job interviews are not, and that's the problem.
In fact, the dating analogy points toward a saner way for small organizations (as most software teams ought to be) to find people. Get to know one another in a relaxed way. See if there are common interests and values. Do things together. Eat and drink. This is how humans behave.
There are other analogies to look at too - auditions might be one.
In fact, the dating analogy points toward a saner way for small organizations (as most software teams ought to be) to find people. Get to know one another in a relaxed way. See if there are common interests and values. Do things together. Eat and drink. This is how humans behave.
There are other analogies to look at too - auditions might be one.
The problem is that it's much more costly to make a bad pre-hire, if that's what you want to call it, than it is to go on a bad date.
You can't just bring someone in and let them be their self in the office. You have to have someone onboarding their HR stuff, someone onboarding them on to the technical stuff, someone getting them a laptop and access to source control, someone answering their questions, someone tasking them with things. All this takes time away from people who could be making the company money.
You can start reducing these things (don't give them access to source control, give everyone the same initial tasks) but now you're just reducing it back to a job interview.
You can't just bring someone in and let them be their self in the office. You have to have someone onboarding their HR stuff, someone onboarding them on to the technical stuff, someone getting them a laptop and access to source control, someone answering their questions, someone tasking them with things. All this takes time away from people who could be making the company money.
You can start reducing these things (don't give them access to source control, give everyone the same initial tasks) but now you're just reducing it back to a job interview.
Maybe, but the status quo is a reductio.
What's the biggest problem for software companies right now? Attracting good programmers. That's true of startups, anyway, and as startups go so goes the industry. What that tells me is that those who get ahead of the curve and figure out how to grow teams better are going to have an edge. This is a big deal, and job interviews suck so badly that there is room for innovation.
What's the biggest problem for software companies right now? Attracting good programmers. That's true of startups, anyway, and as startups go so goes the industry. What that tells me is that those who get ahead of the curve and figure out how to grow teams better are going to have an edge. This is a big deal, and job interviews suck so badly that there is room for innovation.
Who says you have to do all that?
This is why job interviews are Hard. They involve making judgements about people on fragmentary evidence. You get better at it with experience, but it's never easy and hard to train.
Actually, these days I find hiring managers harder, since it's much more about gut feel than objective criteria.
But saying they're broken is like saying dating is broken. There isn't much of an alternative.
This is why job interviews are Hard. They involve making judgements about people on fragmentary evidence. You get better at it with experience, but it's never easy and hard to train.
Actually, these days I find hiring managers harder, since it's much more about gut feel than objective criteria.
But saying they're broken is like saying dating is broken. There isn't much of an alternative.
That was what happened when I was interviewed for this job 10 years ago. Unfortunately, we don't do it anymore.
The interviews consisted of HR talk, technical meetings with more people than I can remember, lunch at a local restaurant where we talked about the industry and a few tech topics, and more tech. interviews in the afternoon.
By the end of that very long day, they knew me well enough and I knew them well enough. Sometimes I wish we were still small enough that we had the time/inclination to hold that kind of interview.
The interviews consisted of HR talk, technical meetings with more people than I can remember, lunch at a local restaurant where we talked about the industry and a few tech topics, and more tech. interviews in the afternoon.
By the end of that very long day, they knew me well enough and I knew them well enough. Sometimes I wish we were still small enough that we had the time/inclination to hold that kind of interview.
> “I’m an egomaniac who has spent vast amounts of time
> Googling this nearly useless knowledge, but will ask
> you to regurgitate it to me without the aid of a search
> engine, and then judge you on how much it makes you
> sweat.
Developers hire other developers that think like themselves.
Technically oriented developers hire other technically oriented developers.
A mediocre developer won't be able to distinguish who knows their stuff or not. But at least getting team fit / communication / personality right is half the battle.
Technically oriented developers hire other technically oriented developers.
A mediocre developer won't be able to distinguish who knows their stuff or not. But at least getting team fit / communication / personality right is half the battle.
This spirit of the article is good, but two of the three example questions are bad. I ask candidates about projects on their resume. I ask them deeper questions about those projects. Many people get excited about cool things they have built and will tell me about all the details.
If you cannot clearly explain the interesting details of a project you should be familiar you are either not that smart, are taking credit for an entire project that you were only a small part of (this happens pretty often) or I am too dumb to understand the concepts (I like to think I am pretty smart and this never happens).
I also ask why they want to work here. Many people don't really know and that is OK. Many want to move into management, although they will never say it directly, and that is usually a red flag.
If you cannot clearly explain the interesting details of a project you should be familiar you are either not that smart, are taking credit for an entire project that you were only a small part of (this happens pretty often) or I am too dumb to understand the concepts (I like to think I am pretty smart and this never happens).
I also ask why they want to work here. Many people don't really know and that is OK. Many want to move into management, although they will never say it directly, and that is usually a red flag.
Apparently, the one core qualification for software development is to write radical, but philosophical articles to no end about it.
> All these questions do is scream, “I’m an egomaniac who has spent vast amounts of time Googling this nearly useless knowledge
Quite the opposite. The original list of questions is absurdly long, but it is an amazingly precise synthesis of what a good front-end developer should know. The three questions proposed are not nearly enough for hiring someone technical. You need to probe for knowledge, that will make passion and interest surface.
Quite the opposite. The original list of questions is absurdly long, but it is an amazingly precise synthesis of what a good front-end developer should know. The three questions proposed are not nearly enough for hiring someone technical. You need to probe for knowledge, that will make passion and interest surface.
When interviewers start lobbing questions that have no relevance to what it means to be a programmer, just smile sympathetically and relax, act like you have just been informed you will be required to work with passionless programmers.
What will blow your mind is that you can ace these interviews without being able to write a line of code to save your own life. Just do what Ken Jennings does when he practices for jeopardy: memorize every esoteric fact you can find. This is not a small task, I built a Web app to store and randomly quiz myself on all potential questions in a domain. I have about 9000 factoids in there, I wow the pants off these non programmers, and made the mistake of picking a place that refucture the codebase and I have to scurry around to fix it or they will use their political connections to blame the problems on me.
After they are done playing jeopardy with you give them the Joel test, they will get a 3 or 5 of 12.
What will blow your mind is that you can ace these interviews without being able to write a line of code to save your own life. Just do what Ken Jennings does when he practices for jeopardy: memorize every esoteric fact you can find. This is not a small task, I built a Web app to store and randomly quiz myself on all potential questions in a domain. I have about 9000 factoids in there, I wow the pants off these non programmers, and made the mistake of picking a place that refucture the codebase and I have to scurry around to fix it or they will use their political connections to blame the problems on me.
After they are done playing jeopardy with you give them the Joel test, they will get a 3 or 5 of 12.
Great, yet another article continuing the tradition of thinking software development is an easy discipline, but it's our mindset that makes us special.
Good luck developing anything mission critical with a team of low paid googlers.
One day even people in our profession might come to actually have some self-respect for what we do. Software development is a hard and challenging discipline - to trivialize it by pointing at guide-books and Q&A forums just demonstrates a total lack of understanding for what we do.