|
harold aptroot wrote: So what are you looking for
Just making a vented comment. 
|
|
|
|
|
It's a valid comment. And while Google's 'How many ping pong balls fit in a 747?' type question might have worked at one point, people are now training themselves for these.
The true indicator is how well people construct a mental model of the software system they are working with, and how well they can manipulate that model. If we see an unwanted symptom, what fault(s)/failure(s) in the software can enable that to happen?
I always ask people to explain a system they are familiar with, not because I want to know it, but because I want them to explain how well they do. I occasionally get the 'can't talk about the system at my last job' response, so I ask them to talk about something else - Uni project, hobby project, etc.
People who have great mental models are able to diagnose defects simply by the symptom. I've seen this myself - one guy saying 'It can't possibly happen', another saying 'It has to be an off-by-one error in this part' - and being right.
|
|
|
|
|
NeverJustHere wrote: I occasionally get the 'can't talk about the system at my last job' response
That doesn't fly with me. They should be able to describe the system and how they solved problems in general terms without discussing specifics or infringing on their former employer's IP concerns. In a sense, this shows how capable they are of abstracting the problem from its domain.
Software Zen: delete this;
|
|
|
|
|
That is putting unfair pressure on people: I had to sign a NDA at a previous gig and was handed a lawyer's letter when I left reminding me to keep my mouth shut. Ok, it was probably a bit OTT but I would just tell you I can't talk about that, but I can talk about the one before that. What would be the problem with that?
|
|
|
|
|
Any previous project would do, but there are damned few jobs that you can't at least say something about it. Even back when I was a contractor for the DoD I could describe projects in general terms and the problems I solved on my resume and in interviews without violating the terms of my security clearance.
It's a judgement call on your part. If your prior employer specializes in XYZ business intelligence modelling, and you're interviewing with a company that does WXY business intelligence modelling, then you need to be more circumspect than the case where they want you to write microcontroller code for widgets.
Again, it's a question of how well you can abstract the problem from its domain, reason about the problem, and determine an appropriate solution. Being able to retrospectively analyze a project shows your ability to learn from past efforts and apply those lessons to future tasks.
Software Zen: delete this;
|
|
|
|
|
I understand (and agree with much of) what you are saying, but if I say to you I can't talk about that project, I don't think you should press someone or mark against them for doing so. Let them talk about something that doesn't make them feel uncomfortable. If you pressed me to do it, I would end the interview.
|
|
|
|
|
Agreed. My concern is that I've interviewed a couple of people who were vague about everything they had worked on previously. It wasn't that they didn't want to talk about prior work, it was that didn't know how.
Solitary programmers may be able to work without communicating what they're doing, but in my environment you must be able to communicate.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: My concern is that I've interviewed a couple of people who were vague about everything they had worked on previously. It wasn't that they didn't want to talk about prior work, it was that didn't know how.
Fair point. That is hard. I prefer to talk about personal projects when asked. It also shows that I have an interest outside of work and am trying to keep my skills current. Well, I mean, of course I don't count the Lego project... 
|
|
|
|
|
Gary Wheeler wrote: It's a judgement call on your part. ....
Again, it's a question of how well you can abstract the problem from its domain, reason about the problem, and determine an appropriate solution. Being able to retrospectively analyze a project shows your ability to learn from past efforts and apply those lessons to future tasks.
Yes, but unless the programming job requires a legal background it shouldn't be a requirement that the interviewee must be able to determine what it is legal for them to discuss and what isn't.
Now if you want to pay for them to bring their own lawyer for consultation then that then becomes reasonable. Is that is what you are going to do?
|
|
|
|
|
I was once worried enough about an NDA to consult an attourney. Turns out NDAs are not very enforceable on software developers. They are a kind of legal document designed as a pre-emptive strike to scare people who don't know much about NDAs. They don't cover general questions, and they don't cover coding minutiae.
If you were a senior vice president, you should probably not go blabbing your former employers strategic marketing plans. If you were a salesman, you can get into trouble if you steal the customer list. But if you worked for Amazon, the fact that you were working on an e-commerce app that used the cloud, or a portable device running android-ish is hardly a secret. Little fish don't know big secrets. Practically everybody is working on an e-commerce app that uses the cloud. As long as you aren't very specific about the target market, you can talk coding issues all day and not violate your NDA.
|
|
|
|
|
NeverJustHere wrote: Google's 'How many ping pong balls fit in a 747?'
If any interviewer were to ask me a question like that I would walk. The purpose of the question is to show how clever the interviewer is (for asking it) and how clever you are not (for not having the One True Answer on the tip of your tongue).
If I were feeling kindly that day (like, they served really good coffee) I might respond: "Take a 747. Hire a group of interns to fill it with ping pong balls, having them count each ball as they put it in the plane. Add up their totals".
Arrogant morons.
Software Zen: delete this;
|
|
|
|
|
I had read that they are more interested in your thought process versus if you come up with the correct answer or not.
|
|
|
|
|
Yes, but there's still the One True Thought Process they are searching for.
Software Zen: delete this;
|
|
|
|
|
1) Assuming TSA decided not to allow ping pong balls on any flight(s), answer is zero.
2) Assuming TSA decided to allow boxed ping pong balls only on flight(s) with one per head at the maximum while we can fit only 9 per box , answer is 9.
..and so on. I see many True Through Processes  at this point.
Standing same on your side - I wouldn't prefer answering such questions, though, if the expectation is a single number with no assumptions and/or time and/or access to enough-resources(that can count for me etc..) allowed. He he. But again what a troll-worthy question. 
|
|
|
|
|
Gary Wheeler wrote: If any interviewer were to ask me a question like that I would walk. The purpose of the question is to show how clever the interviewer is (for asking it) and how clever you are not (for not having the One True Answer on the tip of your tongue).
But sometimes it can be fun to see that they don't know the answer.
I once had an interviewer ask me a question. I answered it. Then commented on how unusual it was that I had answered exactly the same question on a bulletin board just a week before.
I really did think it was just an interesting coincidence but his fumbled conversation after that finally made me realize that he had gotten the question from my post.
|
|
|
|
|
I'd just give them an answer that was in the same spirit as the one I give to the question: How long is a piece of string?
I would answer "One less than the number taken to fill it to overflowing".
The other answer is "twice as long as it is from the middle to one end".
Both of which are perfectly correct and absolutely precise. (even if arguably, useless answers)
Just as √2 is the correct answer for the length of the hypotenuse of a right-angled triangle with side-lengths of 1, the answer need not necessarily be expressed as a rational number. 
Smarty pants question would receive a smarty-pants answer. 
"When I was 5 years old, my mother always told me that happiness was the key to life. When I went to school, they asked me what I wanted to be when I grew up. I wrote down 'happy'. They told me I didn't understand the assignment, and I told them they didn't understand life." - John Lennon
|
|
|
|
|
Gary Wheeler wrote: If any interviewer were to ask me a question like that I would walk.
I interview people all of the time.
I ask questions like these at every interview.
The purpose is NOT EVER one true answer. It is about analyzing the person for their response.
Can they solve HUGE problems with lots of unknowns.
How do they approach it, how do they process it, and break it down.
Finally, how do they respond when they hear the problem.
There is no one right answer. In fact, I had a PhD once who belted out the approach to my top 3 questions. Completely nailing them. So I asked a question which is nearly impossible to know the answer to (what happens to a brownie, when pushed out a port of the space shuttle, into space. So that it is going from an atmosphere condition of inside the space shuttle, to outside into space. Describe everything you can think of. Does it explode, implode, etc.)
This is where it is interesting. He completely wigged out. He became physically agitated, he did not know the answer, and it really bothered him. But his response showed me that he may have some social issues. He is used to always being right, and is usually the smartest guy in the room.
The point is, that it was a fun game when he knew the answer, and it was stressful when he did not.
I want the guy who thinks it is a fun game when he does not know the answer, and plays with the question. Turns it around. Asks it differently. States a bunch of assumptions, and then starts developing insights as to what will/should happen and what to look for, what you could test.
I don't really want the answer. There is no ONE right answer. There is no ONE right approach.
There is simply the concept that MOST software is about building the unknown. And if you don't have the skills, to quickly start mapping that unknown to known, and what questions to ask, and to ENJOY the process. You are going to fail. Very rarely do my clients come to me and say "I need you to add 2 integers together and output the result". They ask for things like "We need to automate the filling in of these various forms with data from up to X different sources, and we need it to be correct. I have PEOPLE who do this today, but the computer would be so much faster." (Except that people can think, and programs have a tough time doing what people do). (BTW, in this case, we used 2 monitors and wrote a drag-n-drop interface that updated the other program. The problem was way too "humanistic". But a well-intentioned PhD could have spent years trying to write the system, which would have had to been reviewed by a human anyways).
BTW, if you have a better way to find people who are comfortable with complexity, and have the ability to express how they approach it, given problems that they have never heard of, and you know that your process works in general (nothing is perfect). I AM ALL EARS? (or eyes, since I will be reading it).
As hiring managers, we are trying to find skills. Not what people tell us, but what they truly have.
We need to know our confidence in those skill levels. And we cannot just trust what they tell us. Sometimes 10 years of C++ is really the same 1 year of C++ simply 10 years in row!
HTH
|
|
|
|
|
So, you are sitting across the desk from a guy who is going to give you a six-figure salary, and just wants you to answer a dumb question about ping pong balls and aircraft. Are you really going to blow off the job because you find the question irritating? Have you ever done this in an interview, or is this just wind?
Many people assert that they would blow off an interview because they find a single question to be beneath them. I can't understand this attitude. Far better to answer the question, finish the interview, find out how good the offer is, and then blow off the job if the balance doesn't tip in your favor.
Do people really act this impulsively? Have you ever done it? Have you ever had a candidate do this to you when you were the interviewer?
'Cause I don't think the job market is that hot. But I'm willing to be educated.
|
|
|
|
|
The fundamental question you must ask, either as an interviewer or an interviewee, is "are you a jerk?".
If I'm an interviewee, and they ask me how many paramecia would fill the secretary's bladder, I know they're a jerk. I don't intend to work for jerks.
Software Zen: delete this;
|
|
|
|
|
Just ask how they go about solving problems (get them to give an example) and the big one: what do you do when you really get stuck and the internet isn't giving you any help?
|
|
|
|
|
Post "SND CODZZZ URGNTZZZ" in QA, generally...
No, I agree. How you solve a problem is much, much more important than your ability to find Google, CP, SO, et al. Being able to debug code is important because the thought processes that you develop doing that improve your code generally (IMO, anyway).
It amazes me that everybody in QA has access to possibly the most wonderful debugging tool on the planet in the shape of Visual Studio - but most of 'em can't even use it to find out which value is null. 
Thirty years ago, I'd have killed for VS!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: the most wonderful debugging tool on the planet in the shape of Visual Studio
Windbg. That truly IS an amazing debug tool.
|
|
|
|
|
Saw "Windbag".
|
|
|
|
|
That is its nick name.
You can kernel debug, and then, if you like, switch to a specific process, and debug that.
Its got the ability to break, look at stack variables, and if they are not of interest, do a go. Thus you can break when a particular file gets opened.
It is a very very powerful tool.
|
|
|
|
|
I know the feeling regarding VS. We used to be penalised anytime we used a debugger process. There was a case where four of us were pouring through a COBOL printout trying to debug a failing program. No joy, so to the debugger...
The program took a branch we didn't expect. The cause was a missing full stop which was masked by a blemish on the printer paper where the full stop should have been.
The difficult may take time, the impossible a little longer.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
