Recommendations for interview questions
-
@masonwheeler said in Recommendations for interview questions:
@blakeyrat said in Recommendations for interview questions:
So when designing SQL databases you grab a conference room with a projector and do it directly in the database diagram with your team?
I design SQL databases one of two ways.
- As part of a personal project. There's no team to coordinate with.
- Adding new stuff to an existing database on a mature product, in which case what's needed is already in the spec, and the need to "design" the changes before writing DDL is minimal-to-nonexistent.
I hope someone gives you a greenfield project some day so we can have some good front page content.
-
@blakeyrat said in Recommendations for interview questions:
@masonwheeler said in Recommendations for interview questions:
The thing that I find confusing about all this talk about whiteboarding database schemas is that it sounds a whole lot like UML, which
I know zero about UML. I find whiteboarding a useful tool.
@masonwheeler said in Recommendations for interview questions:
doesn't need to be drawn on a board because there are tools to do it on a computer (which is far more legible!) and
If you have a digital whiteboard, fine! Use it! If you're fine putting PowerPoint's drawing tools up on a projector, fine! Use that! Nobody's saying it HAS to be hand-drawn by pen, you're arguing against ghosts and phantoms.
@masonwheeler said in Recommendations for interview questions:
is almost universally considered a massive anyway, so why does anyone want to do it?
I know zero about UML. I find whiteboarding a useful tool.
@masonwheeler said in Recommendations for interview questions:
Point 1 is particularly significant. A big part of my aversion to drawing stuff out is that people in general, and developers in particular, tend to have terrible handwriting.
So don't use a pen. Have your company buy a projector or one of those big Surface touchscreen TVs or whatever you prefer.
@masonwheeler said in Recommendations for interview questions:
If I want to communicate the written word effectively, I'll use a keyboard so that other people can read it, and I definitely prefer for them to extend me the same courtesy, so I don't have to decipher the arcane heiroglyphics that pass for penmanship in the Information Age.
The point isn't to communicate, it's to discuss. The communication is done later, when whoever drew the whiteboard types/diagrams up a summary of it.
Here's one of my masterpieces I can share without redacting too much:
When @blakeyrat, @boomzilla and myself are all in violent agreement on a subject, that should be a pretty good indication that opinion on the subject is as close to unvarnished truth as an opinion can get.
This is one of those times. Hell, the entire forum is in agreement, save for one person.
-
@polygeekery said in Recommendations for interview questions:
This is one of those times. Hell, the entire forum is in agreement, save for one person.
What if the white board was on a very special train?
-
@polygeekery said in Recommendations for interview questions:
When @blakeyrat, @boomzilla and myself are all in violent agreement on a subjec
Don't forget the Vixen! <3
-
@djls45 said in Recommendations for interview questions:
I see. You're conflating a code test with an algorithm test.
I'm saying that I've seen whiteboard testing done for both.
A code test is to see whether the candidate really does know the language he claims to know. Does he understand the syntax? Is he familiar with the standard library? Et cetera.
Mmhmm.
An algorithm test is to see how the interviewee would approach the problem. Does he break it into separate, manageable chunks? Does he find and address edge cases? Does he know where to look for resources? Will he admit that he doesn't know something?
Sure.
And what does writing things out on a board have to do with either of those?
-
@blakeyrat said in Recommendations for interview questions:
The point isn't to communicate, it's to discuss.
So you discuss things without communicating?
...come to think of it, that actually explains a lot.
-
@accalia said in Recommendations for interview questions:
@polygeekery said in Recommendations for interview questions:
When @blakeyrat, @boomzilla and myself are all in violent agreement on a subjec
Don't forget the Vixen! <3
The one whose mind is perpetually in the gutter, or her opposing twin who barely talks at all?
-
@pleegwat said in Recommendations for interview questions:
@accalia said in Recommendations for interview questions:
@polygeekery said in Recommendations for interview questions:
When @blakeyrat, @boomzilla and myself are all in violent agreement on a subjec
Don't forget the Vixen! <3
The one whose mind is perpetually in the gutter, or her opposing twin who barely talks at all?
botth i think, though i only talk for one of them.
-
@accalia said in Recommendations for interview questions:
i only talk for one of them.
...oh, is that why she doesn't talk much? Because you're always doing it for her?
-
@masonwheeler said in Recommendations for interview questions:
And what does writing things out on a board have to do with either of those?
A code test should really be done with an IDE, since that's where the actual writing of the code will be performed. And with modern IDEs, most code is fairly easy to type in, unless it involves some pretty deeply complicated stuff, like C++ templates.
An algorithm test can be written out on a whiteboard, a blackboard, a notepad, in the dirt on the ground, or anywhere else that is easily drawn and erased, because the development of the process and how the interviewee goes about designing and refining it is the purpose here.
I also probably should clarify that an algorithm test, as I'm using it, is not necessarily the same as a test to write out a particular algorithm, like bubble sort or Dijkstra, etc. It's a test to see what the interview candidate's mental algorithm is to solve a given problem. Seeing how he produces a given sorting or search algorithm may be one way to go about revealing that, but there are other challenges that can be offered as well. @cartman's fruit mettles are a good example of a combination of code and algorithm test. Most of his candidates were not that great on the code part, although a few did all right; but (AFAIK) only one has ever done okay on the algorithm part of it, and IIRC, that candidate's code was only mediocre.
-
@djls45 said in Recommendations for interview questions:
An algorithm test can be written out on a whiteboard, a blackboard, a notepad, in the dirt on the ground, or anywhere else that is easily drawn and erased,
...such as a text editor?
because the development of the process and how the interviewee goes about designing and refining it is the purpose here.
Sure.
I also probably should clarify that an algorithm test, as I'm using it, is not necessarily the same as a test to write out a particular algorithm, like bubble sort or Dijkstra, etc. It's a test to see what the interview candidate's mental algorithm is to solve a given problem. Seeing how he produces a given sorting or search algorithm may be one way to go about revealing that, but there are other challenges that can be offered as well. @cartman's fruit mettles are a good example of a combination of code and algorithm test. Most of his candidates were not that great on the code part, although a few did all right; but (AFAIK) only one has ever done okay on the algorithm part of it, and IIRC, that candidate's code was only mediocre.
And he did them by exactly the method that I'm advocating (or the remote-viewing equivalent thereof): have them work the problem out on a computer and observe how they solve it.
I agree with everything you're saying about algorithm tests here, but I still don't see how any of this requires complicating everything by taking the computer away. (Especially when the specific example you used is a counterexample!)
-
@accalia said in Recommendations for interview questions:
@polygeekery said in Recommendations for interview questions:
When @blakeyrat, @boomzilla and myself are all in violent agreement on a subjec
Don't forget the Vixen! <3
Not to mention myself and Arantor.
-
@masonwheeler Part of the test may include allowing the person to draw diagrams and graphics to illustrate something he's thinking of. A text editor simply cannot do that. The fruit mettles already had a fairly simplistic structure that didn't need extra graphics to illustrate a solution. The data was already formatted in a table that the candidates could look at, and they had to do some basic operations on that data and output another table. That's about the maximum complexity I would want to see without being able to draw images to plan out the system.
Maybe you're one of those people that are able to keep track of three levels of indirection while solving a min-max path that depends on 5 inter-dependent variables, but most people would want to draw pictures to help keep track of that sort of complexity.
-
@djls45 said in Recommendations for interview questions:
@masonwheeler Part of the test may include allowing the person to draw diagrams and graphics to illustrate something he's thinking of. A text editor simply cannot do that. The fruit mettles already had a fairly simplistic structure that didn't need extra graphics to illustrate a solution. The data was already formatted in a table that the candidates could look at, and they had to do some basic operations on that data and output another table. That's about the maximum complexity I would want to see without being able to draw images to plan out the system.
Maybe you're one of those people that are able to keep track of three levels of indirection while solving a min-max path that depends on 5 inter-dependent variables, but most people would want to draw pictures to help keep track of that sort of complexity.
Must just be a personal style thing. I would absolutely not want to draw pictures to help keep track of that sort of complexity; it just wouldn't be helpful to me. (Particularly because I suck at drawing!) If I needed help to keep track of that sort of complexity, I would (and frequently do) open up Notepad and express my train of thought in words.
-
@masonwheeler said in Recommendations for interview questions:
Point 1 is particularly significant. A big part of my aversion to drawing stuff out is that people in general, and developers in particular, tend to have terrible handwriting. (Myself very much included!) If I want to communicate the written word effectively, I'll use a keyboard so that other people can read it, and I definitely prefer for them to extend me the same courtesy, so I don't have to decipher the arcane heiroglyphics that pass for penmanship in the Information Age.
Counterpoint: all diagramming tools are awful and actively hostile to productivity. All of them. I haven't found one UML tool that wouldn't be at least ten times slower than scribbling on a whiteboard. Besides, when whiteboarding, you're usually explaining things to the audience as you write them, so bad writing is okay as long as it just vaguely reminds you what was there.
You can go for a touchscreen or a digital whiteboard or something, but I'm not sure there's any software that digitizes handwriting into UML, so that's the same thing.
@masonwheeler said in Recommendations for interview questions:
It's always been literally "write this code/algorithm up here on the whiteboard, 'so that I can see what your thought process is like,'" which is the same thing @accalia brought up.
Yeah, but you don't have to spell out perfect compilable code. The point of a whiteboarding interview question is primarily to get the candidate to talk about the solution, brainstorm it, and present it to the interviewer in a way that's comprehensible and understandable. It's possible to do that with just words, or with just code, or while writing code, but for most people the most productive and quickest way to do it is to draw some stuff on a whiteboard.
-
@masonwheeler said in Recommendations for interview questions:
I'm saying that I've seen whiteboard testing done for both.
I thought you said you've never seen whiteboarding ever nor ever worked with anybody ever who suggested using a whiteboard ever.
@masonwheeler said in Recommendations for interview questions:
So you discuss things without communicating?
You know what I meant you pedantic dickweed.
@masonwheeler said in Recommendations for interview questions:
(Particularly because I suck at drawing!)
That is completely irrelevant, and I don't understand why you keep bringing it up.
-
@blakeyrat said in Recommendations for interview questions:
@masonwheeler said in Recommendations for interview questions:
I'm saying that I've seen whiteboard testing done for both.
I thought you said you've never seen whiteboarding ever nor ever worked with anybody ever who suggested using a whiteboard ever.
Yes. I've seen whiteboard interviewing done, and been subjected to it, which I always found strange since it's not something that was actually used in the real job.
@masonwheeler said in Recommendations for interview questions:
So you discuss things without communicating?
You know what I meant you pedantic dickweed.
No, to be perfectly frank what you said there makes no sense.
@masonwheeler said in Recommendations for interview questions:
(Particularly because I suck at drawing!)
That is completely irrelevant, and I don't understand why you keep bringing it up.
Because it's extremely relevant. Why would I want to use a tool that's not helpful to me?
-
@masonwheeler said in Recommendations for interview questions:
(Particularly because I suck at drawing!)
Boxes. Circles. Lines. My 2 year old can draw those.
And, yes, like I said, if drawing things out doesn't float your boat, so be it. It's a personal preference. I just don't understand why you've been fighting other people when they say their own personal preference.
-
@the_quiet_one
Maybe he doesn't get into heaven unless he converts at least 1 person a year to the realization that whiteboards are evilFiled under: Religions are more than just God things
-
@masonwheeler said in Recommendations for interview questions:
Because it's extremely relevant. Why would I want to use a tool that's not helpful to me?
You have a brain, right?
About 20% of the meaning of the board is your writing, and about 80% is in your brain. The board just serves to visually remind your brain of shit you were talking about a few minutes ago. (Spatial memory is very strong.)
-
@blakeyrat said in Recommendations for interview questions:
You have a brain, right?
About 20% of the meaning of the board is your writing, and about 80% is in your brain. The board just serves to visually remind your brain of shit you were talking about a few minutes ago. (Spatial memory is very strong.)
...and how is that any different from keeping it in Notepad?
-
@masonwheeler said in Recommendations for interview questions:
...and how is that any different from keeping it in Notepad?
I never said it was.
The point of any kind of note-taking is to remind your brain to remember stuff, not to end up with a polished, complete, document you can then hand off to someone else and expect them to fully understand.
-
- Writing is faster for most people than typing.
- Visual diagrams with relationship arrows provide extra visibility & context that text notes don't for most people
- In an interview setting, seeing the messy flow of thought (which whiteboarding facilitates more than notes in written language) can help to understand how the candidate is going through the thought process.
- We're all just trolling you by arguing with your position for the sake of argument.
Take your pick :P
-
@masonwheeler said in Recommendations for interview questions:
I agree with everything you're saying about algorithm tests here, but I still don't see how any of this requires complicating everything by taking the computer away. (Especially when the specific example you used is a counterexample!)
You're complicating things by adding the computer.
-
@masonwheeler said in Recommendations for interview questions:
Must just be a personal style thing.
That's probably true, and that's fine. Some people are picture-thinkers. Others are word-thinkers. It sounds like you're more of a word-thinker. I think I'm more of a picture-thinker.
On the other side of this stage is the explanation of what someone is thinking, and for that, pictures are almost universally better for broad-stroke descriptions. Words are good for precise details. It's almost the difference between drawing a pizza and writing down the recipe to make one.
Running an interview, you want to see both. The person can tell you the wordy part of that, but they need to be able to show how they think, too.
-
@masonwheeler said in Recommendations for interview questions:
@the_quiet_one said in Recommendations for interview questions:
Have you ever actually built a large-scale application from the ground up?
No, I've generally worked on mature products.
But what you (and @RaceProUK and @Maciejasjmj) seem to be missing is that this stuff you're talking about, it's not the developers' job anyway! That's what you have PMs for. If someone's trying to get me to write specs, something's gone very wrong somewhere.
I think designing data flow is part of SA's job, and designing how to convert data from another schema to current schema while making them work during transition is SA/AP's job.
-
@masonwheeler said in Recommendations for interview questions:
@accalia said in Recommendations for interview questions:
handwriting is involved but what i want to see is your thought process.
Then have them code something--at a real computer--and look over their shoulder as they do so. That's infinitely less stressful, useless, and irrelevant than making them use a whiteboard.
No, no, no, standing over me is extraordinarily nerve-wracking even at my job in front of people who I already appreciate my skills.
-
@dangeruss said in Recommendations for interview questions:
@raceprouk said in Recommendations for interview questions:
Why are developers afraid of picking up a pen? :P
Because most developers are lefties, but society forced us to be righties, thus causing awful handwriting.
I learned to write in the 70s...they didn't do that shit then.
My handwriting sucks regardless.
-
@masonwheeler said in Recommendations for interview questions:
@the_quiet_one said in Recommendations for interview questions:
Have you ever actually built a large-scale application from the ground up?
No, I've generally worked on mature products.
But what you (and @RaceProUK and @Maciejasjmj) seem to be missing is that this stuff you're talking about, it's not the developers' job anyway! That's what you have PMs for. If someone's trying to get me to write specs, something's gone very wrong somewhere.
If I am doing something non-trivial I need to a bit of writing out. Whether it is boxes, pseudo-code, english if/then clauses, listing all the permutations.
A good example of this was one of the complicated validations we have to do in our new system. The business user sent us a fairly long email describing it in their terms.
I put permutations into Excel to get all the relevant code branches. Explicitly showing the commonalities across each validation. The person who coded it ultimately thought it was a great help.
-
@polygeekery said in Recommendations for interview questions:
@dragnslcr said in Recommendations for interview questions:
@thebread I hope this thread is giving you good ideas for interview questions.
"Are you familiar with TDWTF forums?"
"Yeah, I am on there all the time."
"I thought so. OK Mr. Wheeler, we have decided to pursue other applicants..."LOL, if someone actually asked me that at an interview...I'd have to quickly judge which answer was the right one.
Because I KNOW some of you would hire me, right, RIGHT ???
-
@accalia said in Recommendations for interview questions:
@polygeekery said in Recommendations for interview questions:
When @blakeyrat, @boomzilla and myself are all in violent agreement on a subjec
Don't forget the Vixen! <3
Me too, but I was late to the party. Sorry, actually had to do some work today.
-
@karla
Well, I guess that explains why you're not a mod
-
@accalia said in Recommendations for interview questions:
@pleegwat said in Recommendations for interview questions:
@accalia said in Recommendations for interview questions:
Don't forget the Vixen! <3
The one whose mind is perpetually in the gutter, or her opposing twin who barely talks at all?
botth i think, though i only talk for one of them.
Part of me thinks I should disagree with you on principle, but in this case I really can't. Communication with coworkers FTW.
@masonwheeler said in Recommendations for interview questions:
...oh, is that why she doesn't talk much? Because you're always doing it for her?
Upvoting is easy. Coming up with replies that contribute is hard. (Although obviously that's not always a requirement around here. :p )
-
@karla said in Recommendations for interview questions:
My handwriting sucks regardless.
If you get me to write on a whiteboard with my right hand, you'll see terrible handwriting. If I then switch to my other hand, you'll see that I'm very strongly right handed; my left hand has similar ability with a pen that you'd expect from a chimpanzee.
Whiteboarding stuff is dead useful though. Anything you can't explain on one whiteboard is probably too difficult to explain to another developer at all; they'll see the concepts, but won't really integrate them into a usable whole without that big picture. Even a bad, ugly diagram is far better than none.
-
@dkf said in Recommendations for interview questions:
@karla said in Recommendations for interview questions:
My handwriting sucks regardless.
If you get me to write on a whiteboard with my right hand, you'll see terrible handwriting. If I then switch to my other hand, you'll see that I'm very strongly right handed; my left hand has similar ability with a pen that you'd expect from a chimpanzee.
Whiteboarding stuff is dead useful though. Anything you can't explain on one whiteboard is probably too difficult to explain to another developer at all; they'll see the concepts, but won't really integrate them into a usable whole without that big picture. Even a bad, ugly diagram is far better than none.
While the principle of doing whiteboard question is sounding, there is one problem for me - I do not write on vertical surface very well. To me, the stress created is far over that of having someone watch over my shoulder while writing code.
Please give me something I could write on table, or give me a keyboard that I can type.
-
@cheong Again: the point is not to make readable, perfect text. You do that later when the discussion is done. The point is to write symbols that remind your brain what you were thinking about at the time you wrote those symbols. All the information is stored in your brain, you just use the whiteboard as a memory aid.
Penmanship doesn't matter.