Re: On Interviewing and Interview Questions

About personality, I would first focus on whether the person is a team player.

There are exceptions, but with the scale of today's application, most likely one has to work with others. A comparatively smart non-team player is the worst type of people you want on a team.

If a person is not that smart, that's fine, there is always tasks for junior.
If a person is smart and also a team player, great!
if a person perceives himself as smart and not a team player. There is not much he can do, other than promoting stupid ideas by force.

Comment on Re: On Interviewing and Interview Questions

Replies are listed 'Best First'.
Re^2: On Interviewing and Interview Questions by rvosa (Curate) on Aug 26, 2005 at 10:39 UTC
Team player is very important! I've worked on a project where one guy went off for months to work, more or less in secret, on an "interesting" problem, and came up with an "interesting" (but useless) solution - haemorrhaging money in the process. He went away.	[reply]
Re^3: On Interviewing and Interview Questions (Beware of a guy in a room) by eyepopslikeamosquito (Archbishop) on Aug 26, 2005 at 11:04 UTC
Yeah, this is what Jim McCarthy calls Beware of a guy in a room (point 6). Curiously, it's usually the most brilliant developer who goes dark. Years ago, the top programmer of a company we were dealing with got away with saying "it will be ready next month" for 18 months without ever allowing anyone to see his code until it was finished! All developers, no matter how brilliant, must make their code available for public review in modest (fortnightly, say) increments. Update: see also: Beware of a guy in a room (youtube)	[reply]
Re^4: On Interviewing and Interview Questions by DrHyde (Prior) on Sep 06, 2005 at 10:29 UTC
That is mostly a failure of management. Be honest now, most programmers would do that if they knew that deadlines and requirements were of no consequence.	[reply]
Re^2: On Interviewing and Interview Questions by Your Mother (Archbishop) on Aug 27, 2005 at 04:54 UTC
I understand what you mean but “team player” for many has come to be management code for “yes man.” I like to see a strong independent streak in everyone I work with. That doesn’t mean they can’t work together but that they can work alone. A couple of the other stories above are horrifying but taking one for example: if the group’s manager lets a prima donna get away without, say, a simple code review/discuss/update at least once a month, it’s not the player that’s the problem. Update 20210524: typo.	[reply]