A list of lists of interview questions(github.com)
github.com
A list of lists of interview questions
https://github.com/MaximAbramchuck/awesome-interview-questions
88 comments
Surprised to have never heard of him. That was really funny!
If you're new to him, you're in for some fun. The spider article is great:
http://www.27bslash6.com/overdue.html
Man, that is funny as hell! Thanks for sharing.
I looked at the first few Android question lists and the questions were terrible. "What are the four API classes used for sensors?" Are you kidding me?!? I have over 10 years of experience building Android apps and I have no idea of the answer -- and I've probably used them! Along with the thousand other apps and classes in the framework. If someone asked me that question I'd kindly explain that I'm no trivia master, that's what documentation is for and walk away.
When interviewing for senior (read: C-suite) positions, I sometimes try to gauge how someone reacts to dumb questions. Ignoring it is bad. Walking out is bad. Explaining why it’s wrong is good. Trying to get at the intended question is best.
Probably not what’s going on here. But human systems require debugging as much as technical ones.
Probably not what’s going on here. But human systems require debugging as much as technical ones.
I had an interview where the interviewer didn't understand amortized complexity.
* thought pushing n elements into an empty vector took O(n) amortized time (it's just O(n) guaranteed)
* thought a hashmap lookup took O(1) amortized time (it's O(1) expected not O(1) amortized).
I tried to gently correct him but he insisted on his views and I felt like I had to drop it so we could discuss other things also felt like I was dinged for it.
On the other hand I've been on the other side of the table, and can appreciate that interviewing people is hard too.
* thought pushing n elements into an empty vector took O(n) amortized time (it's just O(n) guaranteed)
* thought a hashmap lookup took O(1) amortized time (it's O(1) expected not O(1) amortized).
I tried to gently correct him but he insisted on his views and I felt like I had to drop it so we could discuss other things also felt like I was dinged for it.
On the other hand I've been on the other side of the table, and can appreciate that interviewing people is hard too.
Sometimes pushing into a vector is O(n), but typically not. So it’s the penalty of allocating new data memory when the underlying array needs a resize that’s amortized for multiple push calls.
Similarly with a typical hashmap, the keyspace should occasionally collide, meaning non-edgecases would amortize to O(1) for multiple inserts.
Similarly with a typical hashmap, the keyspace should occasionally collide, meaning non-edgecases would amortize to O(1) for multiple inserts.
When interviewing for senior (read: C-suite) positions, I sometimes try to gauge how someone reacts to dumb questions.
This can be OK as long as you preface it with something like, "If you don't mind I'd like to ask something that might like a dumb question..."
If not -- if you're deliberately gaming the candidate (or cloaking your true intent in any way) -- then of course the better candidates are going to smell that right away. At which point walking out the door is not only permissible - but arguably the only response that make any sense.
This can be OK as long as you preface it with something like, "If you don't mind I'd like to ask something that might like a dumb question..."
If not -- if you're deliberately gaming the candidate (or cloaking your true intent in any way) -- then of course the better candidates are going to smell that right away. At which point walking out the door is not only permissible - but arguably the only response that make any sense.
Well if thats what you practice on your interviews then you might miss out at some people that might react the way you want them to react and be a good fit.
I would personally walk away as well, its not like am some kind of superstar, I just feel that I won't be a good match to a company that asks questions that I feel are not needed. The way I see it an interview is always two ways. The company is interviewing me to see if am a good fit and I am interviewing the company to see if they are a good fit for me since I'll be spending at least 8 hours a day 5 days a week of my time working for that company.
Personally so far what I've seen working ok for us in human systems is to just have a talk with the person we are interviewing, see what his/her hobbies are and generally feel if he/she is a good fit.
I would personally walk away as well, its not like am some kind of superstar, I just feel that I won't be a good match to a company that asks questions that I feel are not needed. The way I see it an interview is always two ways. The company is interviewing me to see if am a good fit and I am interviewing the company to see if they are a good fit for me since I'll be spending at least 8 hours a day 5 days a week of my time working for that company.
Personally so far what I've seen working ok for us in human systems is to just have a talk with the person we are interviewing, see what his/her hobbies are and generally feel if he/she is a good fit.
> Personally so far what I've seen working ok for us in human systems is to just have a talk with the person we are interviewing, see what his/her hobbies are and generally feel if he/she is a good fit.
Bingo. Thats basically our interview process. I could ask stupid technical gotchas but thats idiotic. Better to ask pointed questions like: oh you like to program micros on the side, if you've programmed SPI before tell me what your most fun debug session involving that entailed.
These questions tell me more than anything like fizzbuzz can. You dig into details as much/little as you need to based on the replies but I honestly think the people you want shine though with their stories, not their rote knowledge.
If someone started spouting off intentionally wrong things in an interview as stated in this comment tree, I would call it a day and say thanks for all the fish, but I'm not starting off having to rebut 2+2=5 for this company. Even if that is a tactic for discussion, lets just have the discussion, as it stands that just makes me not want to work there as now what is the day to day like? Do I have to prove the world isn't flat constantly? Better to not find out and look elsewhere, even the weird cs quizz jobs are better than trying to deal with those kind of dynamics.
Bingo. Thats basically our interview process. I could ask stupid technical gotchas but thats idiotic. Better to ask pointed questions like: oh you like to program micros on the side, if you've programmed SPI before tell me what your most fun debug session involving that entailed.
These questions tell me more than anything like fizzbuzz can. You dig into details as much/little as you need to based on the replies but I honestly think the people you want shine though with their stories, not their rote knowledge.
If someone started spouting off intentionally wrong things in an interview as stated in this comment tree, I would call it a day and say thanks for all the fish, but I'm not starting off having to rebut 2+2=5 for this company. Even if that is a tactic for discussion, lets just have the discussion, as it stands that just makes me not want to work there as now what is the day to day like? Do I have to prove the world isn't flat constantly? Better to not find out and look elsewhere, even the weird cs quizz jobs are better than trying to deal with those kind of dynamics.
> I would personally walk away as well, its not like am [sic] some kind of superstar
You’re a perfectly-reasonable person. I also think you’d find the work those positions do frustrating.
You can’t tell a multibillion-dollar client they’re asking stupid questions. You also can’t ignore the potential problems their asking them hints at. Walking away, usually, isn’t an option. Similarly, a CEO and CFO must be able to productively field “dumb” questions from potential investors, acquirers, distributors and yes, employees. “Dumb question” shouldn’t frankly exist as a category in certain relationships. Only opportunities to improve mutual understanding.
Not every role is for everyone. And not everyone is for each role. Part of interviewing, in my opinion, is not only qualifying for fit with the company but also fit with the role. (For solely internally-facing roles, I prefer a let’s get a walk/beer/take a hike together chat.)
You’re a perfectly-reasonable person. I also think you’d find the work those positions do frustrating.
You can’t tell a multibillion-dollar client they’re asking stupid questions. You also can’t ignore the potential problems their asking them hints at. Walking away, usually, isn’t an option. Similarly, a CEO and CFO must be able to productively field “dumb” questions from potential investors, acquirers, distributors and yes, employees. “Dumb question” shouldn’t frankly exist as a category in certain relationships. Only opportunities to improve mutual understanding.
Not every role is for everyone. And not everyone is for each role. Part of interviewing, in my opinion, is not only qualifying for fit with the company but also fit with the role. (For solely internally-facing roles, I prefer a let’s get a walk/beer/take a hike together chat.)
Purposely saying something wrong seems a little dishonest, like you are setting a trap. It really sets things off of the wrong foot if your first interaction proves that not only can you conceal your true thoughts and express something that you aren't thinking, and not only are you willing to do it, but on top of it all it doesn't take much motivation before you start. It would be a lot better to wade in to something you honestly didn't know about, so that your expression of not knowing enough to ask good questions was not only completely realistic but also truthful. If you can't think of anything that you don't know enough about to ask good questions, then you either need to evaluate yourself better or get out more. ;)
To see it from another perspective, imagine what your response would be if you found out that someone you were interviewing was pretending to know something they didn't, just because they preferred to work with people smart enough to notice they were faking.
To see it from another perspective, imagine what your response would be if you found out that someone you were interviewing was pretending to know something they didn't, just because they preferred to work with people smart enough to notice they were faking.
> Purposely saying something wrong seems a little dishonest
I agree. I never proposed that. I said I purposely ask questions the person at hand might consider dumb.
Note that many classic “dumb” questions are actually interesting, if not in their specifics then in why so many people ask them.
> imagine what your response would be if you found out that someone you were interviewing was pretending to know something they didn't
Again, asking dumb questions doesn’t require lying. Everyone goes through a dumb-question asking phase when learning. (I do.) The worst effect of this might be the interviewee walking away thinking me uninformed. Which, if I’m interviewing them, I probably am (relative to them). That’s why they’re being sought! In any case, people thinking I’m dumb is a fair price to pay for a well-tempered executive.
[1] https://en.m.wikipedia.org/wiki/Dunning–Kruger_effect
I agree. I never proposed that. I said I purposely ask questions the person at hand might consider dumb.
Note that many classic “dumb” questions are actually interesting, if not in their specifics then in why so many people ask them.
> imagine what your response would be if you found out that someone you were interviewing was pretending to know something they didn't
Again, asking dumb questions doesn’t require lying. Everyone goes through a dumb-question asking phase when learning. (I do.) The worst effect of this might be the interviewee walking away thinking me uninformed. Which, if I’m interviewing them, I probably am (relative to them). That’s why they’re being sought! In any case, people thinking I’m dumb is a fair price to pay for a well-tempered executive.
[1] https://en.m.wikipedia.org/wiki/Dunning–Kruger_effect
A better way to frame this type of question might be "[Important Person X] asks you [Stupid Question Y], how would you respond?"
Sometimes when I'm interviewing people I say things that I think are wrong because I want them to challenge and defend positions. I always preface these sections of the interview with a moment to explain that I expect them to push back and disagree if I say something they think is wrong so that we can talk about it. The reason I give that warning is because I want to stop people from just agreeing because they're in an interview and don't want to seem disagreeable.
That's just a new spin on a trick question and is quite frankly bullshit. You are right away telling the person you are going to be deceptive and they need to catch your lie. It's a terrible tactic.
A large portion of my job, and the role I interview for, involves discussing alternatives, taking positions, attacking and defending them. I use hypothetical situations, and defend what I think are incorrect positions, to see how the candidates defend their positions. To me, this is an efficient test of a few things - can they identify the best position, will they resist the bad arguments I put forth to advocate for my bad position, and will they give intelligent and clear arguments to defend their position?
It's a huge part of the job and the idea that I shouldn't test people on it strikes me as absurd. You seem like you're jumping to interpret what I've said negatively.
It's a huge part of the job and the idea that I shouldn't test people on it strikes me as absurd. You seem like you're jumping to interpret what I've said negatively.
[deleted]
There's a wonderful mechanism we've invented for this purpose. It's called tenure.
Imagine a candidate who came in and said, "I'm really great at this computer stuff, just trust me!" but refused to show a resume, prior work, to even talk about it.
"Push back, it's fine, trust us!"
This ends up filtering for people who can deal with your bullshit,(as in: have other options) and don't mind doing so. So, good for you, I guess, but you could get better people by fixing your culture and being straight with people.
Imagine a candidate who came in and said, "I'm really great at this computer stuff, just trust me!" but refused to show a resume, prior work, to even talk about it.
"Push back, it's fine, trust us!"
This ends up filtering for people who can deal with your bullshit,(as in: have other options) and don't mind doing so. So, good for you, I guess, but you could get better people by fixing your culture and being straight with people.
I don't understand any part of what you've written.
Regarding tenure, I don't understand how that's applicable to hiring new people.
Regarding the imaginary candidate I think this is supporting my point - no? Just like you wouldn't want to trust someone who offered no evidence for their abilities, I want to discern whether people can stand up to arguments and make compelling arguments for their case. In order to get the evidence I put them in a position to stand up to arguments and put arguments forward.
Regarding your thoughts about how this filters people, I think you've summarized it incorrectly. Even if I agreed that asking people to argue against me in an interview was "bullshit" then that wouldn't filter only "for people who can deal with your bullshit,(as in: have other options) and don't mind doing so". Clearly, the people who have no other option would also put up with the tactic, as they have no other option. Thus, the filter, as you put it, filters only people who don't mind putting up with the interview question. This is actually a point in my favor because if the candidate is not comfortable arguing for or against positions in a professional context then they would not be a good fit for the role.
Finally, you suggest "fixing your culture and being straight with people." I think I am being straight with the interviewee. I tell them upfront that if I say anything they disagree with I want them to push back on me, that I think disagreement and debate is positive and sometimes necessary. Again, the role requires disagreeing and pushing back on arguments, often in situations where there is pressure not to, so I think giving friendly encouragement and setting up a hypothetical situation where I will disagree with the candidate is a very reasonable thing to do.
Regarding tenure, I don't understand how that's applicable to hiring new people.
Regarding the imaginary candidate I think this is supporting my point - no? Just like you wouldn't want to trust someone who offered no evidence for their abilities, I want to discern whether people can stand up to arguments and make compelling arguments for their case. In order to get the evidence I put them in a position to stand up to arguments and put arguments forward.
Regarding your thoughts about how this filters people, I think you've summarized it incorrectly. Even if I agreed that asking people to argue against me in an interview was "bullshit" then that wouldn't filter only "for people who can deal with your bullshit,(as in: have other options) and don't mind doing so". Clearly, the people who have no other option would also put up with the tactic, as they have no other option. Thus, the filter, as you put it, filters only people who don't mind putting up with the interview question. This is actually a point in my favor because if the candidate is not comfortable arguing for or against positions in a professional context then they would not be a good fit for the role.
Finally, you suggest "fixing your culture and being straight with people." I think I am being straight with the interviewee. I tell them upfront that if I say anything they disagree with I want them to push back on me, that I think disagreement and debate is positive and sometimes necessary. Again, the role requires disagreeing and pushing back on arguments, often in situations where there is pressure not to, so I think giving friendly encouragement and setting up a hypothetical situation where I will disagree with the candidate is a very reasonable thing to do.
I think the OP might've just meant playing the devils advocate which is often a good way of encouraging discussion.
Indeed, all that would do is make me walk out and say good luck with that tactic. I'll find somewhere else to work.
Lying to a candidate immediately sets a pretty bad image of the company. While someone might try to put things in the best light as possible, maybe with some small exaggeration. That is a huge difference between "I am lying to you"
Isn't 'lying' a bit strong here? When ALittleLight said
> I always preface these sections of the interview with a moment to explain that I expect them to push back and disagree if I say something they think is wrong so that we can talk about it.
I interpreted that as, at least implicitly, flagging to the interviewee that not everything the interviewer says will accurately represent his/her views. Perhaps it could be made clearer, but it doesn't seem like the intent is to deceive.
> I always preface these sections of the interview with a moment to explain that I expect them to push back and disagree if I say something they think is wrong so that we can talk about it.
I interpreted that as, at least implicitly, flagging to the interviewee that not everything the interviewer says will accurately represent his/her views. Perhaps it could be made clearer, but it doesn't seem like the intent is to deceive.
Yes, I intentionally didn't go into to much detail and I think that's obscured what I was trying to say. I explicitly tell the candidate that I may defend points I disagree with and that I want them to push back if they disagree. Furthermore, the interview question where I do this is about a hypothetical project where we are prioritizing work that needs to be done in order to ship a project. While I didn't offer the clarity in the earlier comment, I don't think there's a way it could fairly be interpreted as lying or deceiving.
The poster literally said they were going to intentionally say things that they know are false.
That's pretty much the definition of a liar and outright deceptive.
Besides that, the tactic of trying to be debative and in this case outright dishonest and slightly combative is an incredibly terrible method for interviews.
Honestly the poster should be banned from giving interviews.
That's pretty much the definition of a liar and outright deceptive.
Besides that, the tactic of trying to be debative and in this case outright dishonest and slightly combative is an incredibly terrible method for interviews.
Honestly the poster should be banned from giving interviews.
The poster is using an interview technique of creating an imaginary scenario, e.g. "deal with a work colleague who is advocating a sub-optimal position". This seems entirely reasonable.
It seems to me that you've jumped to a very strong conclusion, based on a brief conversation that you have interpreted in the least charitable way possible.
It seems to me that you've jumped to a very strong conclusion, based on a brief conversation that you have interpreted in the least charitable way possible.
Walking out is bad? For you maybe, because you just lost out on a potential senior candidate.
Why not just do a “Describe a time...” behavioral question ?
In an interview both sides should put their best foot forward, assuming positive intent and trust. Purposefully asking “dumb questions” on the hopes someone picks up on the game, and then plays it as you expect, seems like a suboptimal approach.
In an interview both sides should put their best foot forward, assuming positive intent and trust. Purposefully asking “dumb questions” on the hopes someone picks up on the game, and then plays it as you expect, seems like a suboptimal approach.
> Why not just do a “Describe a time...” behavioral question ?
I find “describe a time when” answers mostly useless. Interviewing, at a senior level, is a proxy for time on the job. Senior people must constantly deal with information flow. Being able to pick up on when to add to or correct that flow is key.
Note that this doesn’t have to be done in a pretentious way. My favourite way to do it is to discuss the company’s R&D. I will almost always know less than the interviewee. Their ability to accurately communicate in that context is vital.
Again, this only applies at senior positions. Lower down, one expects managers to know their subject matter with more detail. You can’t do the “go solve this approximate problem” thing one can with senior management.
I find “describe a time when” answers mostly useless. Interviewing, at a senior level, is a proxy for time on the job. Senior people must constantly deal with information flow. Being able to pick up on when to add to or correct that flow is key.
Note that this doesn’t have to be done in a pretentious way. My favourite way to do it is to discuss the company’s R&D. I will almost always know less than the interviewee. Their ability to accurately communicate in that context is vital.
Again, this only applies at senior positions. Lower down, one expects managers to know their subject matter with more detail. You can’t do the “go solve this approximate problem” thing one can with senior management.
I think you hit on a critical skill that's possibly more important than knowing all this code trivia: how to not know something.
I want to give out questions people don't know because I want to hear how they talk through understanding the question, what they know that might be related and why, and how they'd go about finding out. Hearing all of that is far more interesting to me.
I want to give out questions people don't know because I want to hear how they talk through understanding the question, what they know that might be related and why, and how they'd go about finding out. Hearing all of that is far more interesting to me.
[deleted]
If you answered like that, I'd ask if you can start tomorrow.
You are in the minority. I said something like this, more tactful, in a very recent interview. The question was related to troubleshooting a performance issue on Linux. I answered, with the process and tool I would use and how I thought it would help, what I was looking for etc, high level
The interviewer response was along the lines of 'anyone can spout off command names, but what's the flags and parameters, and what do they mean'. I answered I don't know the exact syntax, I'd have to read the man pages or my notes. The interview was cut short and I was removed from consideration.
Note, this was not a FANG, was not for SRE or Systems admin type role either. But this was my experience. The majority of interviews want you to repeat trivia bullshit because it makes their job 'easier'.
Note, this was not a FANG, was not for SRE or Systems admin type role either. But this was my experience. The majority of interviews want you to repeat trivia bullshit because it makes their job 'easier'.
It's funny. It's like the interview process is designed to build bad habits. If somebody needs to troubleshoot, I'd prefer someone who reads manpages. If you need an actual algorithm for something, I'd prefer someone who has a look around for libraries first and if it's really necessary, cracks a fucking book and figures out what the right answer is, rather than over-confidently pulling utter bullshit out of their ass on the fly.
Honestly though, annoying interviews are just no-poach 2.0. It's a form of wage suppression if you really think about it.
Honestly though, annoying interviews are just no-poach 2.0. It's a form of wage suppression if you really think about it.
Obviously the person has to have a clue what they are doing. But I would never expect them to have the details memorized. "I'd look at the docs and stack overflow" is a valid answer. As long as they had the thought process established of what was being accomplished. They knew where they were going, they worked out a reasonable solution but maybe didn't remember some command flag. Memorization is useless. How does the person aproach and solve the problem is far more important.
I don't understand the wage suppression part. Elaborate?
The harder it is to change jobs or explore opportunities in parallel, the less employers have to compete.
There was a whole lawsuit about no-poach where a group of employers chose explicitly not to compete by agreeing to not hire each other's employees. I believe the same effect can be had by simply adding friction to the structure of the market itself.
What's amusing to me is the brilliance of it. It essentially exploits egos in the workforce to suppress their own wages.
There was a whole lawsuit about no-poach where a group of employers chose explicitly not to compete by agreeing to not hire each other's employees. I believe the same effect can be had by simply adding friction to the structure of the market itself.
What's amusing to me is the brilliance of it. It essentially exploits egos in the workforce to suppress their own wages.
> You are in the minority
One way to think about the interview process is that it's a way for small, compatible, minorities to find each other.
To make that happen, you have to be real during the interview. It's not for everyone, I know :)
One way to think about the interview process is that it's a way for small, compatible, minorities to find each other.
To make that happen, you have to be real during the interview. It's not for everyone, I know :)
I wish I could downvote you. You have completely missed my point. I am absolutely 'real' during an interview, the problem is, the other side of the table doesn't WANT what my 'realness' is. They want cookie cutter CS grads.
I feel like you've dodged a bullet.
Agreed, but it is still a frustrating experience. Though since this is the experience I have had, I have a i play the game to get a job. I never know if the next interview will ask the same shit but, I expect it at this point and I still hate it.
From my side (hiring) it's rough too. All candidates seem prepared for this stupid game. Then I'm like, hey, show me some hobby code of some thing you shipped. Let's talk about your bugs, how you ship? Why you pick that stack? Watching a candidate click through their own buggy stuff teaches me so much, so fast about the person.
My experience is that candidates are ready for trivia and sample/theory but are not ready to brag about their own cool shit. Talk about how great you are and what you learned, defend your choice, evaluate where to improve. That's what we do every day. we only use the white board for drawing arch-pictures/diagrams, and the occasional dickbutt.
In fact, that's my new (and only) whiteboard question.
My experience is that candidates are ready for trivia and sample/theory but are not ready to brag about their own cool shit. Talk about how great you are and what you learned, defend your choice, evaluate where to improve. That's what we do every day. we only use the white board for drawing arch-pictures/diagrams, and the occasional dickbutt.
In fact, that's my new (and only) whiteboard question.
I have a lot of 'cool stuff' I would love to elaborate on, personal projects and home lab stuff. Though again, in my experience, companies don't want to hear this. They want to see stupid ass 'bubble sort this, merge sort that, fixx buzz without modulus' crap. I can't do that, I don't -want- to do that. I am not a programmer (despite my handle). I can script, I can automate, but I should NOT need to know every damn CS algorithm under the sun for a fucking NON dev, non programmer, role. I'm tired of this interview process. Tech is the only industry I know of, that has multiple interviews of varying nature, including phone, web camera/ doc collab, on site multiple days, etc etc. I once told a non-tech person the type of gauntlet needed to even get an INTERVIEW let alone a JOB in this realm, and their question was aptly "why the hell would you ever put up with that?". Their job interview was: resume -> onsite with manager, hired.
I loathe this type of interview bullshit culture, and it more than anything else is driving me out of the industry. Sure I'm not Jon Skeet, but I do my job and I do it well. Continuing with these types of interviews and company shit, makes me want to go be an electrician or mechanic or anything the hell else.
I loathe this type of interview bullshit culture, and it more than anything else is driving me out of the industry. Sure I'm not Jon Skeet, but I do my job and I do it well. Continuing with these types of interviews and company shit, makes me want to go be an electrician or mechanic or anything the hell else.
Yeah, I don't remember is a perfectly valid answer to a question like that IMO.
Especially in any language where you have suggestions in your IDE, just remembering where it is would be fine. "Oh yeah that's in the IO.Sensors namespace" or wherever it is.
If there are some incredibly common pitfalls or footguns, those are a better test, especially if you can ask something like what the difference between two methods is. But even that is pushing it.
Operators, on the other hand, I think are fair game. If you're doing Javascript you'd better be able to tell the difference between `==` and `===`, even if the answer is "== does magic things that surprise people and I don't remember what they are, so I stick to ===".
Especially in any language where you have suggestions in your IDE, just remembering where it is would be fine. "Oh yeah that's in the IO.Sensors namespace" or wherever it is.
If there are some incredibly common pitfalls or footguns, those are a better test, especially if you can ask something like what the difference between two methods is. But even that is pushing it.
Operators, on the other hand, I think are fair game. If you're doing Javascript you'd better be able to tell the difference between `==` and `===`, even if the answer is "== does magic things that surprise people and I don't remember what they are, so I stick to ===".
[deleted]
In the last set of interviews I've conducted (for junior/midlevel C#/vue.js devs - still hiring if anyone wants to experience this for themselves and is in London - link at the bottom) I've settled on a list that more or less all start with "can you tell me about a time when...", or some other variation on asking about experience. One's I've had a some success with...
- A bug that was particularly difficult to track down? (What did you learn? What would you do differently?)
- A time you disagreed with your manager/lead? (And a time when in retrospect you think you were right/wrong/got your way/didn't get your way?)
- a piece of work took much longer than you anticipated? (what did you/would you do to prevent it happening again?)
- you had to quickly learn a new thing?
For more specific technical stuff I like to try and find questions that allows someone to show off, rather than tests if they know just one thing. We're using Typescript, C# and TDD...
- what new or upcoming features in C# do you most like using/would like to get the chance to use/really wish were out already?
- what parts of Typescript do you find most useful vs Javascript?
- what makes a good test?
- what makes a bad test?
I don't see why anyone wants to ask anything of the what does using `ref int foo` mean, especially when there's lots of competition in the job market at the moment!
https://www.linkedin.com/jobs/view/full-stack-c%23-vuejs-typ...
- A bug that was particularly difficult to track down? (What did you learn? What would you do differently?)
- A time you disagreed with your manager/lead? (And a time when in retrospect you think you were right/wrong/got your way/didn't get your way?)
- a piece of work took much longer than you anticipated? (what did you/would you do to prevent it happening again?)
- you had to quickly learn a new thing?
For more specific technical stuff I like to try and find questions that allows someone to show off, rather than tests if they know just one thing. We're using Typescript, C# and TDD...
- what new or upcoming features in C# do you most like using/would like to get the chance to use/really wish were out already?
- what parts of Typescript do you find most useful vs Javascript?
- what makes a good test?
- what makes a bad test?
I don't see why anyone wants to ask anything of the what does using `ref int foo` mean, especially when there's lots of competition in the job market at the moment!
https://www.linkedin.com/jobs/view/full-stack-c%23-vuejs-typ...
- what makes a good test?
- what makes a bad test?
So I don't have a fixed good answer for any of these - what I'd like to see is that it's something the interviewee has thought about/read about. I'm also interested in how deep the knowledge goes, can they discuss these things? Have they tried other approaches and so on. That sort of thing is quite experience dependant, of course.
Possible good test answers (I'd expect maybe one or two - bonus points if you can talk about them as lived experience rather than text book)
Tests one thing/clear what causes a failure
Documents the code well
Describes the purpose of the code
Something about naming
Something about BDD
Something about arrange act assert
Something about how quickly it runs
Discussion of relative merits of unit, integration, e2e etc.
What's a Bad test answers...
Brittle (bonus if you mention this in relation to refactoring)
Asserting multiple things
Tautological
Very slow to run (with which I'd follow up with "any exceptions to this)
Plus you'll get lots of points if you bring up something I've not thought of before.
Possible good test answers (I'd expect maybe one or two - bonus points if you can talk about them as lived experience rather than text book)
Tests one thing/clear what causes a failure
Documents the code well
Describes the purpose of the code
Something about naming
Something about BDD
Something about arrange act assert
Something about how quickly it runs
Discussion of relative merits of unit, integration, e2e etc.
What's a Bad test answers...
Brittle (bonus if you mention this in relation to refactoring)
Asserting multiple things
Tautological
Very slow to run (with which I'd follow up with "any exceptions to this)
Plus you'll get lots of points if you bring up something I've not thought of before.
Those are junior level?
How much experience must someone have to be a junior developer in your opinion?
How much experience must someone have to be a junior developer in your opinion?
The people I've been interviewing have had between 1-4 years experience. For people with effectively zero experience these questions have limited value, and I try to tailor the questions to the level of person I'm interviewing.
That style of question is perhaps the most horrible one to subject someone to.
Instead of focusing on the task of talking to someone, you end up trying to recollect instances of each kind of event, evaluate them on whether you can talk about them openly, whether they can sound impressive even if they actually are, whether they will sound plausible, whether you can recall enough details to avoid being called out as a bullshitter etc.
The people who can appear to answer these questions best are either a) prepared for them specifically or b) psychopaths who can comfortably lie and twist stories with a smile on their face on the spot.
Instead of focusing on the task of talking to someone, you end up trying to recollect instances of each kind of event, evaluate them on whether you can talk about them openly, whether they can sound impressive even if they actually are, whether they will sound plausible, whether you can recall enough details to avoid being called out as a bullshitter etc.
The people who can appear to answer these questions best are either a) prepared for them specifically or b) psychopaths who can comfortably lie and twist stories with a smile on their face on the spot.
Well I'm very happy if people have prepared for these questions beforehand, and I try and give people hints and nudges to help get good answers out of people (I want people to do the best they can!).
Do you think there are any style of questions that do work well?
Do you think there are any style of questions that do work well?
I think a healthy mix of open-ended questions (such as those in your post) and closed-ended questions is key. Open-ended questions are useful for getting at how an engineer goes about solving a problem. Closed-ended questions reveal whether that engineer has the tools to solve the problem to begin with.
Interesting thoughts. What would you think of as a good closed ended question? I always worry that if I'm to specific I'll get false negatives (do they really not know what protected means or have they had a brain fade under pressure?)
The goal of the individual interview should be answering: "I have some particular problems I need to solve soon, and some undefined future problems to solve later, can hiring this person help solve the immediate problems and do I think they'll be an asset in solving future problems?"
Once you've got some questions in mind that should answer that for an individual, you need to reformulate the questions so that most of them are at least semi-objective and have a scoring criteria that you can use to rank multiple people who passed "yes" on the overall question -- and perhaps a threshold too if you think you can afford "yes, but let's wait to see if we can find someone even better".
In this light, 'tell me about a time when' types of questions aren't often very useful unless they're directly related to an issue you're currently facing and you've precommitted to some sort of score for types of answers. e.g. "time when you've disagreed with boss (or coworker)" might be relevant because your team currently has some drama dynamics. So 0 points for "Oh I never have disagreements", 1 point for "some story that makes me think they won't get eaten alive here and/or be a total pushover, the story details don't really matter", 0 points (or negative) for anything that raises a total asshole flag. The question about new C# features might be useful as a proxy for answering whether they'll be helpful in the future, i.e. do they keep up-to-date about things and keep learning, so maybe that's worth a point if they can name something and maybe you can ask a different question as another proxy to normalize across interests (they might not care about PL features but something else). And depending on the real concern being proxied, sometimes you can just ask about the real concern directly.
If you can, make a work-sample test: https://sockpuppet.org/blog/2015/03/06/the-hiring-post/
Once you've got some questions in mind that should answer that for an individual, you need to reformulate the questions so that most of them are at least semi-objective and have a scoring criteria that you can use to rank multiple people who passed "yes" on the overall question -- and perhaps a threshold too if you think you can afford "yes, but let's wait to see if we can find someone even better".
In this light, 'tell me about a time when' types of questions aren't often very useful unless they're directly related to an issue you're currently facing and you've precommitted to some sort of score for types of answers. e.g. "time when you've disagreed with boss (or coworker)" might be relevant because your team currently has some drama dynamics. So 0 points for "Oh I never have disagreements", 1 point for "some story that makes me think they won't get eaten alive here and/or be a total pushover, the story details don't really matter", 0 points (or negative) for anything that raises a total asshole flag. The question about new C# features might be useful as a proxy for answering whether they'll be helpful in the future, i.e. do they keep up-to-date about things and keep learning, so maybe that's worth a point if they can name something and maybe you can ask a different question as another proxy to normalize across interests (they might not care about PL features but something else). And depending on the real concern being proxied, sometimes you can just ask about the real concern directly.
If you can, make a work-sample test: https://sockpuppet.org/blog/2015/03/06/the-hiring-post/
Are you recruiting public speakers or software engineers?
I looked over the Linux questions, and they were pretty bad:
Q.1: What is the core of Linux Operating System? Shell
Kernel
Command
Script
Terminal
I mean... If they asked me about that at an interview, that'd be a huge red flag. I wouldn't consider this list when studying for interviews... It is sad for me how many stars and forks this list has. Hopefully, it's much better for other languages/topics.
Q.1: What is the core of Linux Operating System? Shell
Kernel
Command
Script
Terminal
I mean... If they asked me about that at an interview, that'd be a huge red flag. I wouldn't consider this list when studying for interviews... It is sad for me how many stars and forks this list has. Hopefully, it's much better for other languages/topics.
Is it supposed to be a list of good questions you should ask, or crap questions you should prepare to get asked?
The repository name is "awesome-interview-questions". So far, of the 3 lists I've looked at, [1] was a page where someone apparently deleted random swathes of text in the middle of the content and utterly unusable as a result, and [2] and [3] were both full of grammatically poor questions that ask about minutiae of C++, get it wrong, and don't realize that C++11 exists.
I think it's supposed to be a list of good questions to ask, but it's actually a compilation of lists that people sent the author with very little to no curation actually done.
[1] http://placement.freshersworld.com/power-preparation/technic...
[2] https://pangara.com/blog/cplusplus-interview-questions
[3] http://a4academics.com/interview-questions/57-c-plus-plus/41...
Edit: Just opened up a Java list for #4... and it said that LinkedList was usually better performance over ArrayList. That is not correct; ArrayList is usually better (because of cache locality). So I'm now 4 for 4 on bad lists out of this site.
I think it's supposed to be a list of good questions to ask, but it's actually a compilation of lists that people sent the author with very little to no curation actually done.
[1] http://placement.freshersworld.com/power-preparation/technic...
[2] https://pangara.com/blog/cplusplus-interview-questions
[3] http://a4academics.com/interview-questions/57-c-plus-plus/41...
Edit: Just opened up a Java list for #4... and it said that LinkedList was usually better performance over ArrayList. That is not correct; ArrayList is usually better (because of cache locality). So I'm now 4 for 4 on bad lists out of this site.
This really seems to be the trend with "Awesome" lists. It's not often they appear to have much curation at all, it's frustrating to see them end up with thousands of stars. Often an order of magnitude more than many open source projects.
I quite enjoyed the Erlang questions. Apparently "what is Erlang" is a common Erlang interview question.
I quite enjoyed the Erlang questions. Apparently "what is Erlang" is a common Erlang interview question.
Generally speaking, I consider them a noobtrap for two reasons.
First off, many of the resources are written and submitted by people who have no place teaching others - and are writing almost purely to self-promote and have something to show to employers.
Second, even if some of the resources in there are of decently high quality, the probable best schema for how to use and integrate that resource is going to be bound up in a textbook written by Someone Very Important. Along with all the stuff you really need to know anyway.
Scrap that, three reasons. Finding and aggregating these kind of links for your personal use is of value: it develops your taste and sense of what resources to veto, and what to collect, and is a meta-skill applicable everywhere you have a search engine and some curiosity.
In '17 and early '18 I wasted hundreds and hundreds of hours collecting "the perfect" set of bookmarks for various things I want to learn, and my collection method has basically been to scrape these kinds of lists and apply a surface-level "ooh sounds cool" filter to what I pick up. Obviously, I learned very little doing this, and almost never open such links except as part of a half-hour flight of fancy.
Perhaps if you're of intermediate/expert-level, these factors aren't that important to you - if a couple of links are handy they've served their purpose. But you're probably not going to star the repo. It's mostly thousands of perma-beginners who should be opening textbooks and playing with fundamentals in a REPL who are starring this stuff.
First off, many of the resources are written and submitted by people who have no place teaching others - and are writing almost purely to self-promote and have something to show to employers.
Second, even if some of the resources in there are of decently high quality, the probable best schema for how to use and integrate that resource is going to be bound up in a textbook written by Someone Very Important. Along with all the stuff you really need to know anyway.
Scrap that, three reasons. Finding and aggregating these kind of links for your personal use is of value: it develops your taste and sense of what resources to veto, and what to collect, and is a meta-skill applicable everywhere you have a search engine and some curiosity.
In '17 and early '18 I wasted hundreds and hundreds of hours collecting "the perfect" set of bookmarks for various things I want to learn, and my collection method has basically been to scrape these kinds of lists and apply a surface-level "ooh sounds cool" filter to what I pick up. Obviously, I learned very little doing this, and almost never open such links except as part of a half-hour flight of fancy.
Perhaps if you're of intermediate/expert-level, these factors aren't that important to you - if a couple of links are handy they've served their purpose. But you're probably not going to star the repo. It's mostly thousands of perma-beginners who should be opening textbooks and playing with fundamentals in a REPL who are starring this stuff.
I'm furrowing my brow at this one:
"A file is unable to be restored from tape due to several device and media errors. What is most likely the cause?
Media errors usually indicate that the tape media is damaged, or that the tape drive heads need cleaning."
I've read a few of the questions from other categories and I really can't say any of them have been "awesome".
"A file is unable to be restored from tape due to several device and media errors. What is most likely the cause?
Media errors usually indicate that the tape media is damaged, or that the tape drive heads need cleaning."
I've read a few of the questions from other categories and I really can't say any of them have been "awesome".
You’d be amazed at how many people apply for jobs and lie on their resumes. Sometimes you need some canary questions to weed those people out. They only seem stupid to you because you know the answers.
A lot of the Python ones seem like fairly poor phone screen questions to me. I like to ask my candidates to solve a realistic problem just like they would if they were working at a desk with me. Q&A where they either know the answer or do not are awful. "Me: Do you know this random fact about python? Them: No... Crickets: <awkward cricket noises>". <-- All I've learned from this is that they don't know that fact and I have zero idea of their coding and problem solving ability.
Instead we ask them to pair program on a live IDE and tell them that using Google is okay (copy/pasting code is not). I don't care if you have the standard library memorized, I care if you can solve problems and have the experience to understand how your code can fail and how to make it robust. I care if you can write clean code and then later easily refactor it when I add some complications to the problem. I care if you know how to make it perform well, etc.
Testing for Linux skills? Give them a broken VM/Vagrant image and ask them to troubleshoot it, fix it, and install and configure some things. Testing for Ansible/Puppet/Chef knowledge? Ask them to do all of the above and send you the playbook to recreate the fixed image from your broken image.
Interviewing is hard and if you haven't spent many hours thinking on it, setting it up, testing it against your current employees, and figuring out some kind of score sheet so it isn't 100% subjective, then everyone is going to have a bad time.
Instead we ask them to pair program on a live IDE and tell them that using Google is okay (copy/pasting code is not). I don't care if you have the standard library memorized, I care if you can solve problems and have the experience to understand how your code can fail and how to make it robust. I care if you can write clean code and then later easily refactor it when I add some complications to the problem. I care if you know how to make it perform well, etc.
Testing for Linux skills? Give them a broken VM/Vagrant image and ask them to troubleshoot it, fix it, and install and configure some things. Testing for Ansible/Puppet/Chef knowledge? Ask them to do all of the above and send you the playbook to recreate the fixed image from your broken image.
Interviewing is hard and if you haven't spent many hours thinking on it, setting it up, testing it against your current employees, and figuring out some kind of score sheet so it isn't 100% subjective, then everyone is going to have a bad time.
Looking at Rails, first list, first question: "What does ruby name refer to?"
I interpreted the question as: "What does ruby's name refer to?" so I guess the precious stone... but no https://www.careerride.com/view.aspx?id=2439
Anyway, this seems exactly what a typical clueless recruiter would ask and try to pattern match the answers to
I interpreted the question as: "What does ruby's name refer to?" so I guess the precious stone... but no https://www.careerride.com/view.aspx?id=2439
Anyway, this seems exactly what a typical clueless recruiter would ask and try to pattern match the answers to
Awesome lists shouldn't just be "huge lists". The first item for Python is pretty awful. Spelling and grammar aside, there's no code formatting so some of the examples don't even make sense.
Rule of thumb - outside the original lists by Sindre Sorhus, most "awesome" GitHub lists are of very poor quality and curation. They're made with good intentions but rarely checked or updated.
I haven't yet reached the stage of giving interviews but I've given some thought to it. Based on the experiences I've read, it seems that technical proficiency should be addressed in a basic way prior to any in-person interview; the latter can then be devoted to gauging fit and personality.
My idea for the technical side is this: procure a fairly subtle, simple, real-life bug that you yourself have had to fix. Ideally it should involve a single class or function and require about an hour for a competent person to fix. Email the code to the candidates along with the parameters that fail, and ask them to resolve the bug and return the code.
This tests a lot of skills that should immediately filter out unsuitable candidates - such as code comprehension, bug-finding, and problem-solving - all in a real-world scenario. You can also change up the scenario every couple of months, and very quickly test whether a candidates' code passes. Has anyone come across something similar to this?
My idea for the technical side is this: procure a fairly subtle, simple, real-life bug that you yourself have had to fix. Ideally it should involve a single class or function and require about an hour for a competent person to fix. Email the code to the candidates along with the parameters that fail, and ask them to resolve the bug and return the code.
This tests a lot of skills that should immediately filter out unsuitable candidates - such as code comprehension, bug-finding, and problem-solving - all in a real-world scenario. You can also change up the scenario every couple of months, and very quickly test whether a candidates' code passes. Has anyone come across something similar to this?
From looking over some examples, there doesn't seem to be much curation: many linked articles are pretty bad (typos, and questions that ask for regurgitation, not understanding).
https://github.com/MaximAbramchuck/awesome-interview-questio...
Suitable question given the apparent level of the list...
As for my current job, I think I only got one directly programming related question. They asked if I had done any work with public key crypto, ie generating and verifying signatures etc. I hadn't, though I knew about the theory and math involved.
Maybe they checked out some of the OSS contributions I referenced though... I'll have to ask now.
Suitable question given the apparent level of the list...
As for my current job, I think I only got one directly programming related question. They asked if I had done any work with public key crypto, ie generating and verifying signatures etc. I hadn't, though I knew about the theory and math involved.
Maybe they checked out some of the OSS contributions I referenced though... I'll have to ask now.
> 15. What is the best multilingual plugin for WordPress?
What???
What???
Anyone have good resources for the whiteboard side of things? Preferably example questions I can go out an practice? I passed a couple of screens with flying colors with the company I'm interviewing at, but now I'm about to go onsite again and do the final whiteboard+general interview. I tend to blank on basic concepts in front of an audience on a whiteboard and then suddenly I'll figure out the answer in seconds after walking out of the interview.
The resource I'm surprised never gets recommended is buy a whiteboard.
I found it incredible how much code you can write and feel competent in before finding out crunch time you literally can't write legibly on a board.
I found it incredible how much code you can write and feel competent in before finding out crunch time you literally can't write legibly on a board.
More is not better - definitely not in interviews.
I only skimmed a couple of bits but there ought always to be more “thinking” questions rather than “remembering/knowledge” questions.
And of course if you wanted to use some sort of list of interview questions the cultural non technical questions (which isn’t the scope of that curation I think) are the most important questions of all I believe.
I only skimmed a couple of bits but there ought always to be more “thinking” questions rather than “remembering/knowledge” questions.
And of course if you wanted to use some sort of list of interview questions the cultural non technical questions (which isn’t the scope of that curation I think) are the most important questions of all I believe.
Jeez... Why don't we cut the crap and convert this to every single CS school curricula.
As many comments here have mentioned, they're not very good questions.
The very first Swift question has a partially incorrect answer. It says that "var array2 = array1" creates a copy of array1. But it's incorrect because a copy isn't actually created until one of them is mutated.
Also from the authors: Jerry and David's Guide to the World Wide Web[1]
[1] https://en.wikipedia.org/wiki/Yahoo!_Directory
[1] https://en.wikipedia.org/wiki/Yahoo!_Directory
So do job interviews for computing-related jobs only ask about your skills and not your personality, goals, or motivation? Or is this list of "interview questions" just focusing on the computing?
In my experience with technical interviews, the majority of time is spent on algorithm questions. This was especially bad at a recent interview I had at Google... all 5 interview rounds were almost entirely focused on one or two algorithm questions without any regard to any of the usual open-ended questions about past challenges, motivation, etc. I even had one interviewer start out asking about an interesting technical challenge I had, and basically cut me off after a minute or two with kind of a "ok thats great lets get on with the whiteboard now."
What algorithm questions did they ask?
Technically I'm not supposed to reveal the exact questions they ask because they have candidates sign an NDA that covers the questions they ask during an interview. But it really shouldn't be too surprising the type of questions they ask, basically similar to stuff you see on sites like Leetcode or books like Cracking the Coding interview. Although very heavy on trees and graphs as opposed to the easier linked list/string/array type problems. Since it was an embedded position, there was on interview round where they asked some stuff about device drivers and Linux Kernel internals. Overall I thought it was a pretty bad interview for how "smart" Google is supposed to be. I thought Amazon actually did a much better job with interview questions, although they were still very algorithm-heavy.
"Curated" seems rather strong. One of the C++ lists has some let's-trip-you-up-on-trivia questions, with bad answers to boot:
> 1. Explain mutable and volatile keywords.
> Volatile keywords are designed to prevent the writer from applying optimisations on objects over which he or she has no control. Any objects that are declared as volatile are just omitted from optimisation to prevent values being changed by coding outside the scope of the original code.
Volatile is a keyword which tells the compiler to not optimize away loads or stores to the relevant memory location (note that volatile is actually a property of memory accesses, not variables, so there's lots of fun corner cases such as volatile bitfields). Actually, strictly speaking, it was originally meant to tell the compiler that the variable was being used to access memory-mapped I/O registers, but it has been shoe-horned to serve other deoptimization uses as well.
> 5. When would you use virtual inheritance?
When you want to find bugs in your compiler. :-) Well, the "correct" answer given in the guide is to not use it, but let's explain what it does anyways. The question really should have been to explain the difference between virtual and regular inheritance, although this does venture into obscure trivia territory because I'm not sure I've ever seen someone use it or want to use it in over a decade of C++ programming...
> 9. What does the acronym OOPS stand for?
This is a worse-than-useless interview question. For starters, I've only heard it as OOP (object-oriented programming), so I have to guess at the S. It has nothing really to do with C++ in particular, especially as C++ has been growing in non-OOP ways in the past decade. Finally, the question doesn't ask to explain or contrast OOP with other paradigms, it just asks you to say that you know its abbreviation. You can know an abbreviation without understanding anything else--I know that SU(3) means Special Unity group of degree 3 but I literally know nothing else about it.
> 13. Define an inline function.
> This is when a function is prefixed and the keyword ‘inline’ is placed before the function definition. They often work faster than normal functions as the compiler replaces the definition of inline functions at compile-time instead of the referring function definition at run-time.
... That's not correct. In C and C++, a function can only have one definition in general. An inline function--which can be specified either by adding the inline keyword or by giving the function body within the class definition--circumvents this rule, instead supplanting it with a rule that the linker must discard all but one copy of the function.
Note that compilers do not generally treat inline as a hint as to whether or not to inline a function, they use their own heuristics instead (incidentally, the register keyword falls in the same boat). Obviously, the function cannot be inlined if its body is not present, but equivalently replacing inline with static would generally have the same impact on inlining.
> 1. Explain mutable and volatile keywords.
> Volatile keywords are designed to prevent the writer from applying optimisations on objects over which he or she has no control. Any objects that are declared as volatile are just omitted from optimisation to prevent values being changed by coding outside the scope of the original code.
Volatile is a keyword which tells the compiler to not optimize away loads or stores to the relevant memory location (note that volatile is actually a property of memory accesses, not variables, so there's lots of fun corner cases such as volatile bitfields). Actually, strictly speaking, it was originally meant to tell the compiler that the variable was being used to access memory-mapped I/O registers, but it has been shoe-horned to serve other deoptimization uses as well.
> 5. When would you use virtual inheritance?
When you want to find bugs in your compiler. :-) Well, the "correct" answer given in the guide is to not use it, but let's explain what it does anyways. The question really should have been to explain the difference between virtual and regular inheritance, although this does venture into obscure trivia territory because I'm not sure I've ever seen someone use it or want to use it in over a decade of C++ programming...
> 9. What does the acronym OOPS stand for?
This is a worse-than-useless interview question. For starters, I've only heard it as OOP (object-oriented programming), so I have to guess at the S. It has nothing really to do with C++ in particular, especially as C++ has been growing in non-OOP ways in the past decade. Finally, the question doesn't ask to explain or contrast OOP with other paradigms, it just asks you to say that you know its abbreviation. You can know an abbreviation without understanding anything else--I know that SU(3) means Special Unity group of degree 3 but I literally know nothing else about it.
> 13. Define an inline function.
> This is when a function is prefixed and the keyword ‘inline’ is placed before the function definition. They often work faster than normal functions as the compiler replaces the definition of inline functions at compile-time instead of the referring function definition at run-time.
... That's not correct. In C and C++, a function can only have one definition in general. An inline function--which can be specified either by adding the inline keyword or by giving the function body within the class definition--circumvents this rule, instead supplanting it with a rule that the linker must discard all but one copy of the function.
Note that compilers do not generally treat inline as a hint as to whether or not to inline a function, they use their own heuristics instead (incidentally, the register keyword falls in the same boat). Obviously, the function cannot be inlined if its body is not present, but equivalently replacing inline with static would generally have the same impact on inlining.
It's "special unitary" but I fully agree with the sentiment =]
I would like to see something like this for statisticians and data scientists.
They're almost entirely ridiculous though I've used a couple when interviewing people.
"How is this an issue?" and "Are you pro-active or reactive" can both lead to exceptionally telling answers. Or just confusion, despair and upset... but certainly have the possibility to almost....
http://www.27bslash6.com/interviews.html