How are the skills used in typical interview questions applied in the real job? [closed]
-
03-10-2020 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
For SQL and C# app dev jobs, the interviewers usually ask questions about tree,graph and linked list traversals using pure C and pointers. In the 3 years I've spent in my job, I've never had to actually
find the path to the 1st node to the right of a given node which is a multiple of the given node
for example
I can see that these skills might be used in jobs where you need to write compilers, drivers and work on the OS kernel. Other than those, where else are these skills used?
Solution
Read some of Joel's answers below.
Especially note something like Schmiel the painter. On the job, you may never have to rewrite a linked list, but you certainly should know under the hood how it works, so that you can avoid Schmiel.
Basically, if you are going to the doctor, you would want that doctor to have studied anatomy. Even though her is just prescribing you some AntiHistamine, a doctor will have learned in medical school that certain medications are bad for people with a 'chronic fractios diamadabada to the inferior femur' or whatever. This kind of in-depth knowledge of EVERYTHING in that specialty can sometimes make the different between life and death, and in Information Technology between life and death of the product, or a job.
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
http://www.joelonsoftware.com/articles/fog0000000319.html
"...spend at least a semester getting close to the machine or you'll never be able to create efficient code in higher level languages. ..."
"...you're programming based on superstition, as far as I'm concerned: a medical doctor who doesn't know basic anatomy, passing out prescriptions based on what the pharma sales babe said would work."
OTHER TIPS
They're not. Many interviews are done by people who don't know how to look for skillful developers, and don't know what questions they should or shouldn't ask.
Most interviewers don't ask technical questions at all, and are more concentrated on meaningless but measurable things, such as the number of projects you've participated to (more is better for those interviewers) or the college degree (higher is better for them). They're happy to hire a person who wasted five years in college learning nothing and then spent ten years doing dozens of e-commerce websites, but they won't hire a person who abandoned college after a few years and was working on a few large technically challenging projects.
Asking at least theoretical questions is better then asking none. This has a benefit of verifying that the person has enough theoretical knowledge, and is not a coder who may have a few years experience with programming, but doesn't really understand what's happening under the hood. Developers who don't have this theoretical knowledge usually ¹ don't know the difference between a list, a linked list a lookup or a hash set, and use them interchangeably.
Good (technical) questions, bad questions
During interviews, you may encounter questions ranging from very good to extremely bad:
(Harmful) "What is the length in lines of the longest working program you have written in that language?"
This question is plainly wrong. I already explained why in another answer. The company where interviewers ask such questions has strong chances to evaluate the productivity of developers in LOC/month. If I have to give an advice: you don't need such job.
This example is different from meaningless but measurable things I've quoted at the beginning of my answer. Here, the interviewer also shows that he doesn't have even the most basic understanding of the metrics by picking one which is well-known for being harmful.
(Bad) "Who is Dennis Ritchie?"
Having at least some culture is indeed very useful, but asking those question misses the point. If the company searches for talented developers who are able to handle software development projects and write code, the fact that they don't know the name of the person who created C and Unix shouldn't matter too much.
(Good) "What are the new features of .NET 4.5?"
This question is much more interesting than the one about Dennis Ritchie. If the candidate can't talk about new features in .NET 4.5, why does he calls himself C# developer? The lack of such knowledge:
Shows that the person may not be really interested in neither the programming language, nor the .NET community,
Indicates that the person may lack some crucial knowledge about the features of C#/.NET other developers use if not daily, at least frequently.
See also the answer by Jerry Coffin which contains a more detailed analysis of this sort of questions.
(Average) "Which one is faster, SSD or RAM?"
This might be useful and shows if the person has enough hardware knowledge, but still, a candidate who can't answer this question shouldn't be rejected.
(Average) "How stack and queue are implemented?"
This is the sort of questions you talk about. They are theoretical, maybe even too theoretical, but knowing what's happening under the hood may help writing better code.
I wouldn't reject a candidate who can't answer this question, but will check more carefully if he really knows the stuff, for example by asking a related but less theoretical question:
(Good) "How can you walk through a tree without using recursion?"
If the candidate answers this question, talking about FILO/FIFO and about the benefits and drawbacks of using a stack versus a recursion for tree traversal, it doesn't really matter that he was unable to answer the previous question.
Asking this question is also a good way to detect candidates who spent years doing their CS degree, but have no field experience.
How to ask good technical questions?
kojiro's comment is interesting and deserves a longer answer:
Sometimes you need to hire someone precisely because they should know more about a subject than you, so by definition you're underqualified to do the interview. You can't reliably get help even doing the interview for the same reason. The best you can do is try to ask questions based on wherever your understanding intersects with the problem domain and hope you get lucky.
Finding good questions may be challenging, especially when you hire your very first developer or when you hire a developer who is expected to be more skilled than all the developers who actually work in the company.
Here are three hints which can help:
Find a friend/colleague you believe to be skilled and ask him to do the reviews. This requires a lot of trust, but can benefit your company a lot.
Find a consultant you believe to be skilled and ask him to assist you or do the technical part of the interview.
Type " interview questions" in Google. It works pretty well, and usually explain possible answers. Example:
Python: those ten questions seem quite good. They are maybe a bit basic, but will help filtering 95% candidates you don't want to hire anyway.
SQL by Dave Pinal, excellent as usual.
C#: a bit too basic, but again, they'll filter 95% candidates,
JavaScript: the questions are more open-ended, which may not be the good thing for technical questions if you want the interview to be short and keep more time for open-ended non-technical questions. The list still helps filtering easily the candidates who don't understand basic concepts in JavaScript.
The drawback of this approach is that the candidate may use the same technique in order to train for the interview. If he reviewed every question of the first website he found in Google, he may score well, without actually having the required skills.
¹ There are some developers who won't be able to explain what a B-tree is (aside that it's "some data structure"), but are still able to develop correctly.
From my experience in my company where I did many interviews, there is a good chance that the person interviewing has no clue on how to do that properly. So they prepared a set of technical questions and calculate a score of that and make that your resume. This however has many drawbacks and should not be done for the following reasons:
You ask point knowledge. If the programmer happens to never have done something in that area, he/she still might be an excellent co-worker, but just doesn't know that particular answer. On the contrast: if someone had prepared for the interview and found the answer to that particular question on the net, you get the right answer, but that person might not have a clue about the actual topic at all.
People are nervous in job interviews. The brain has this great feature to shut down many higher-level areas (like logic) if in panic, which means: if you are nervous, you might not deliver the quality of answers you would in a day-to-day situation. Some people can deal with a stressful situation like an interview, many can not.
With a single, correct answer, you test that persons skill to find that particular answer. This is one of many skills an it co-worker needs, but not the one and only required. Therefore one or two of those questions should be enough to test that area of knowledge, and then other skills should be queried. An interview that only contains problem-solving questions tests the same skill over and over again.
What are good programming tasks questions?
Those famous "Can you write a short program" questions have the huge problem that most programmers cannot write a single line of code without their IDE helping them. But that is in day-to-day working situations no issue at all, because the programmer always has his IDE helping him. So asking things like "Find the error", "Write 50 lines of code that do..." or even simple questions need to take into account, that the applicant does not have his tools (IDE, Google) available.
I for example can answer you basically any question within 1 minute if I have Google helping me, but without Internet connection I appear to be helpless. I call that outsourced memory, and instead of hindering me, it very much helps me to focus on what is really important - understanding the underlaying mechanics - because everything else can be looked up. But don't ask me about details from any random APIs, because I don't know those, I have Google for that.
That said, a good programming task question should not focus on knowing APIs, or special coding skills unless this is an absolute requirement for the job. Knowledge can be gained, so it is better to find out how good that person is in gaining knowledge than to ask what he/she already knows.
A good question for a programming task should be short, simple, able to be coded in every language with only a few lines of code and it - especially - should tell you as much as possible about how the person works and finds answers. Example:
"Write a function in the language of your choice that takes an array of integers and re-orders them in a way that the first integer is afterwards the last, and all others shift accordingly."
The first any applicant should ask at this point is: "Sorry... can you please explain the task?". Because no programmer has been given a clear description on what to do ever. This is followed by the explanation, that the code in questions should do a left-shift of the content of the array with the overflow being added to the right.
This task is so simple, that anyone who graduated any form of programming level should be able to answer properly. This takes into account that the programmer has to work without his tools and that being nervous reduces the ability to think logically. It however still tells you how people solve problems just from the way the question is worded and from the way how people approach it, simply because a left-shift is against the common 'left-to-right' instinct and forces people to think for a second.
There are many possible answers to this question, so taking a close look to the way the code is developed is the important part, not if the solution would actually work. Does the applicant test for null? How is the overflow stored? Is a loop or a mem-set used? How does the applicant verify code correctness? This one simple question tells you an entire biography about how that person works.
What are good general knowledge questions?
Good questions are easy to answer, allow for a broad amount of answers (so called 'open questions') and allow you to learn as much as possible about the applicant as you can in the short time you have.
Examples:
(Asking a C++ programmer): "What other languages beside C++ do you know?"
This is an entry level questions, which gives the applicant a fair chance to bail out at this moment should he not know anything about the topic asked. A 'no' at this point is better than to torment him/her with several more questions that he/she all has to answer with: "Sorry, I don't know anything about that."
I addition it tells you first of all which other languages that person knowns, furthermore you learn how interested that person is to get a more broad view of the programming world, or if you have someone with only a singular language (and therefore feature/techniques) view.
(Next after that, lets say he knows Java): What are the top three differences between C++ and Java in your opinon?"
This is an open question that allows for many answers, so the applicant has a good chance to find at least three. Asking for the (personal opinion) top three not only limits the possible answers, but also forces the applicant to sort based on priority. Still it is (or should be) easy to answer.
This is a simple question that tests a lot of in-depth knowledge about different programming languages. How deep is the knowledge of those topics really? From those answers you can tell a lot about the knowledge and actual understanding of the underlaying mechanics of programming languages. How much that person spent with the dirty details, or if he/she is just someone who links together various API functions with no real clue what happens beneath those.
This concept of entry-level questions followed by simple in-depth knowledge questions can be used for most other topics as well. Always in this scheme: bail-out question, verification question, in-depth question. Another example (from a Java interview):
- "How would you rate your experience with multi-threaded development?"
- "Please name what you think are the top three most important things to consider when developing a multi-threaded application."
- "Please name three classes from the Java API that can help you on developing those applications and give a short description on what they are used for."
These three questions will tell you more than any technical question what the applicant really knows about those topics, while being fair to answer considering point-knowledge and stress level.
So the next time someone asks you 20 coding questions in a row, you know that he or she has basically no idea on how to interview someone properly. ;)
Warning: this is written as (sort of) a comment on @MainMa's answer, but 1) it's too long to fit in a comment, and 2) I think it adds a somewhat different perspective on constructive questions so it's a real answer in itself.
In his answer, @MainMa classifies "What are the new features of .NET 4.5?" as a "good" question.
I beg to differ. As he's phrased it, I'd say this is a fairly mediocre question at best. A good question would be more like: "How does the code you write today differ from the code you wrote N years ago?" (for some value of N less than the years of experience listed on the resume, preferably around 3 to 5).
As he's phrased it, the question is about memorization. Has this candidate memorized the feature list completely? By rights, the one who quotes Microsoft's list the most accurately should be the winner.
What you should care about is his programming. How has this affected his code? Which of those features does he really use? More importantly still, does he display good judgement about when to use which new features, and when older ones suffice perfectly well?
Just being able to say "LINQ" tells you virtually nothing useful about the candidate. Being able to say: "LINQ has helped make my code much more compact and readable because I can express concepts X, Y and Z cleanly and directly, where I previously had to jump through the following flaming hoops to do those things." (or something similar) tells you a lot about the candidate, what kind of code he writes, his judgement, flexibility, and so on. It also gives you a great deal more opportunity for follow-up questions about how this person thinks about problems, writes code, thinks about code, and so on. Finally, it gives you a much better idea of whether this is a candidate who really has N years of experience, or somebody who has one year of experience, repeated N times.
Summary: being able to quote a feature list from a few years ago is useless, and tells you little about the candidate that's likely to be of any real use. The candidate's progress as a programmer is likely to be of a great deal more interest, so it's much better to ask about that more directly.
The reality is that most of the day-to-day tasks most of the developers do in their professional life are trivial; That means some of the questions you face in a job interview might never face you in reality, but that doesn't mean there is no point for asking those questions.
Let say there is an open position in your company and you're currently interviewing people. You have already 20-30 developers in the queue. So how would you choose the best candidate for that position? Let say the most challenging task they have to done in that job is to open a file from file system, read the data line by line, slightly modify it and put it back in to the original file.
Are you going to ask them how would you open a file? I bet you can't see a really big difference between the answers. So you have to come up with a solution to distinguish between the developers who only know how to open a file and those how can develop a bad-ass real-time application. Even tho you don't want them to build such an application, but still you want to hire the best candidate.
Like any other thing in our life, there are some points that you realize you need to go and learn more. If you don't know what is a linked-list, to me as a programmer, that literally means you haven't really reached that point in your professional life to feel that you need to go and learn that specific thing. Why? Simply because you never involved in a project big enough to require you to improve your skills up to that level. If you're in an entry-level, you could say I don't really have any working experience for this specific job, but still if you know it that means you're self-motivated enough to put yourself on the cut above average at least.
The skills required to do these tasks are rarely important. The skills demonstrated in the approach to answering the question and in the subsequent dialogue are the whole point.
When I interview developers I look for (a) smart (b) gets things done (c) will fit in. There is a base level of technical knowledge required to fill any role, which has to go with a willingness to learn and acquire new skills. The interview is about checking those boxes.
My preference is to read code written by an applicant. I don't like canned interview questions, but they provide something to talk about in the absence of code. I prefer to ask about RAII or IOC or the implementation of IDisposable rather than list and collections, but anything will do as long as we can get it technical enough.
The worst fear of the interviewer is of hiring someone who actually doesn't know much about coding. You have to talk about something other than work experience to weed out the fakes.
These questions are for screening out people that can't program. Sometimes people who can't program but know a lot of trivia apply for development jobs, and having them write something that's useful and non-trivial is too time-consuming for an interview.
I can see that these skills might be used in jobs where you need to write compilers, drivers and work on the OS kernel. Other than those, where else are these skills used?
How about writing search engines, web servers, web browsers, word processors, spread sheets, image editors, drawing programs, database servers, bioinformatics, trading programs, games, physics simulators, and so on and so forth.
I will grant you that the majority of software jobs involve pulling data from a database, putting it up on a screen, editing it, scraping it off the screen and putting it back in a database. However, even then, you may eventually run into an application where the constraints can't be satisfied by the built in features of a platform. At that point you can either give up, or reach into your toolbox of algorithms and data structures and take a shot at solving the problem.
Theoretical objects are used for convenience because you are supposed to know what an average tree/graph/list implementation is about thus know how to solve a random traversal problem, but these questions are not about the theoretical objects at all.
They are about being able to work with abstracted model, understanding an abstract problem and solve it with an algorithm of whatever kind. This is pure development skill there, so it sure counts. This is why these question makes sense, not because they are supposed to be accurate real life situations.
