What not to ask technical people in interviews
fusioncube.net
fusioncube.net
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.
"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 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
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 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.
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.
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?
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.
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.
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.
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.
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.
This is the dirty secret of outsourcing.
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.
I don't think modern tools help you with any of the constant decisions needed to hit those marks.
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.
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 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.
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.
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.
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.
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.
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.
Passion is passion. Bad pay is bad pay. They are orthogonal.
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.
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?
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.
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 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.
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.
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 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.
TLDR: I build stuff, it works and I smile.
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?
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.
Working together is a kind of relationship. You don't interview for a relationship.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.