Recommendations for interview questions
-
@the_quiet_one said in Recommendations for interview questions:
You want project managers to write DB schemas?
??? Who said anything about DB schemas?
Do you know what a PM even is?
Yeah. They're the people who interface between the non-technical people who come up with high-level requirements, and the technical people who implement them.
-
@boomzilla said in Recommendations for interview questions:
None of my whiteboard sessions have occurred in the UK. I've drawn on whiteboards with other developers, managers, customers, subcontractors and children. All in the US.
...if you say so. I haven't.
Except the "children" part. I did plenty of drawing on boards back when I was in school. :P
Do you ever collaborate with or explain things to other people?
Yes. I do it all the time, and I'm actually quite good at explaining technical things to other people, if my SO score is anything to judge by. I just don't draw pictures to do it.
-
@masonwheeler said in Recommendations for interview questions:
did plenty of drawing on boards back when I was in school
-
@masonwheeler said in Recommendations for interview questions:
if my SO score is anything to judge by.
The consensus is that it isn't.
-
@masonwheeler said in Recommendations for interview questions:
Do you know what a PM even is?
Yeah. They're the people who interface between the non-technical people who come up with high-level requirements, and the technical people who implement them.
Yeah, no. They're dealing with budgets and labor estimates and contract haggling and ensuring deliverables are on time and stuff like that.
-
@boomzilla OK, terminology confusion. Now your response makes more sense. What do you call the people I described?
-
@masonwheeler
Business Analysts and/or Senior Software Developers.
-
@masonwheeler said in Recommendations for interview questions:
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.
You have PMs that do your, for example, SQL relational design?
Because I've whiteboarded SQL schemas with developers about a billion times, and it's always a huge help.
-
@pjh said in Recommendations for interview questions:
Black swan: https://what.thedailywtf.com/post/788915
Ok - it was messing around with Discourse, but stil..Ok, dragging that CSS into the twenty-first century:
ul.topic-list li:nth-child(2n+2), ul.topic-list li:nth-child(2n+1){ background-color: initial; } ul.topic-list li:nth-child(3n+1) { background-color: #f00; } ul.topic-list li:nth-child(5n+1) { background-color: #0f0; } ul.topic-list li:nth-child(15n+1) { background-color: #ff0; }
-
@masonwheeler said in Recommendations for interview questions:
Who said anything about DB schemas?
It's just the most obviously whiteboard-able thing.
Hell, in SSMS you can basically just draw your whiteboard in the diagram view, and you end up with a functional database. It's pretty great.
-
@masonwheeler said in Recommendations for interview questions:
if my SO score is anything to judge by.
It's not. That site is garbage, and internetpointzzz are useless.
-
@thebread I hope this thread is giving you good ideas for interview questions.
-
@blakeyrat said in Recommendations for interview questions:
@masonwheeler said in Recommendations for interview questions:
Who said anything about DB schemas?
It's just the most obviously whiteboard-able thing.
ISTM it's the most obviously not-needing-whiteboarding thing.
Hell, in SSMS you can basically just draw your whiteboard in the diagram view, and you end up with a functional database. It's pretty great.
...because you can trivially do it all in software instead.
-
@masonwheeler Want to have your mind blown? That visual designer he's talking about? It's a digital whiteboard.
-
@masonwheeler said in Recommendations for interview questions:
@blakeyrat said in Recommendations for interview questions:
@masonwheeler said in Recommendations for interview questions:
Who said anything about DB schemas?
It's just the most obviously whiteboard-able thing.
ISTM it's the most obviously not-needing-whiteboarding thing.
Hell, in SSMS you can basically just draw your whiteboard in the diagram view, and you end up with a functional database. It's pretty great.
...because you can trivially do it all in software instead.
Do you have a projector set up in your office?
-
One thing you could do is to anonymize something that your company actually does (a domain-specific problem that your company has already solved) and ask how the interviewee would solve that problem.
For example, when I was interviewing for my current job, I was presented with the following problem:
- You are in a schoolyard with a bunch of children, and you have a bowl of skittles. Each kid can come up to you and get a skittle. How do you ensure that every kid receives the same number of skittles?
- Ok, now the skittles are separated by color, and each kid cannot have the same color twice in a row, but they can have as many as they want each time they come up. How do you enforce that?
- Ok, now every kid must have received one color before any kid can receive a different color. Do you need to change anything in your process? If so, what should you change?
- One last new requirement (scratch the previous one): you need to be able to see what color skittle(s) each kid received, and in what order. Do you need to change anything? If so, what?
I was asked this on a phone interview, but it could easily work as a whiteboard problem to sketch out possible solutions.
-
@masonwheeler said in Recommendations for interview questions:
@the_quiet_one said in Recommendations for interview questions:
You want project managers to write DB schemas?
??? Who said anything about DB schemas?
Uuuh, everyone here, when they're talking about writing boxes and arrows on whiteboards. Do you really think japonicus's drawing is something a project manager should be drawing?
-
whiteboards
I count 16 whiteboard-easels in the office right now, without getting up from my desk. I know there are several more in meeting rooms, and many of those rooms have at least one wall covered with whiteboard paint.
-
@dragnslcr said in Recommendations for interview questions:
@thebread I hope this thread is giving you good ideas for interview questions.
I was going to say it's a rookie mistake for someone to come here and ask such a question, but he's been around for 3 years, so there's no excuse for his ignorance. You asked such a question here, this is what you're going to get. @theBread should have known that by now.
-
@blakeyrat said in Recommendations for interview questions:
@masonwheeler said in Recommendations for interview questions:
if my SO score is anything to judge by.
It's not. That site is garbage, and internetpointzzz are useless.
(but serious, agree. SO points are negative utility)
-
@djls45 said in Recommendations for interview questions:
One thing you could do is to anonymize something that your company actually does (a domain-specific problem that your company has already solved) and ask how the interviewee would solve that problem.
Pfft, too amateur. The real pros have them work on a problem you haven't solved yet so that you get some free labor from the candidate.
-
@masonwheeler said in Recommendations for interview questions:
I'm actually quite good at explaining technical things to other people, if my SO score is anything to judge by. I just don't draw pictures to do it.
So you're one of those autists that @blek was talking about? It explains so much.
-
@raceprouk said in Recommendations for interview questions:
@masonwheeler It's arrogant for you to think you know better than those who have several years more experience than you. It's even more arrogant to think that your experiences are the only ones that matter.
Wow, projecting much?!?
-
@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..."
-
@the_quiet_one said in Recommendations for interview questions:
@djls45 said in Recommendations for interview questions:
One thing you could do is to anonymize something that your company actually does (a domain-specific problem that your company has already solved) and ask how the interviewee would solve that problem.
Pfft, too amateur. The real pros have them work on a problem you haven't solved yet so that you get some free labor from the candidate.
Maybe the candidate will have an approach that no one had thought to take and that is more efficient than the current one, so that result is still possible.
It wasn't an interview, but someone here posted a work problem that he was trying to solve on his own time, and with a bit of help from several people here, he dropped the 3-day runtime to ~20 seconds, IIRC.
-
@polygeekery said in Recommendations for interview questions:
So you're one of those autists that @blek was talking about? It explains so much.
-
@masonwheeler said in Recommendations for interview questions:
@raceprouk said in Recommendations for interview questions:
@masonwheeler It's arrogant for you to think you know better than those who have several years more experience than you. It's even more arrogant to think that your experiences are the only ones that matter.
Wow, projecting much?!?
Several of us are pointing out the many ways in which you're wrong, and you accuse me of arrogance?
You do this every time. To you, only your opinion matters. Only your experiences count. Only you can be right. That is the definition of arrogance. To deny you are arrogant only serves to confirm it.
Do yourself a favour. Pull that stick out from your arse and listen to others for a change. You might actually learn something.
-
@raceprouk said in Recommendations for interview questions:
To deny you are arrogant only serves to confirm it.
Yay for witch trials! If denial of the crime can be held as evidence of the crime, how is a true innocent to defend himself?
-
@masonwheeler Throughout this thread we've pointed out our rationale for whiteboarding, including for initial architecture diagrams and SQL schemas as part of functional design. In response you've:
a.) Stated that you've never done such tasks, therefore it's a if other people have.
b.) Misunderstood people, thinking they're talking about the kinds of diagrams only PMs would make, when we've mentioned repeatedly we're talking about technical diagrams.
c.) Trivialized the exercise into just "drawing boxes and arrows" as if it's child's play.If whiteboarding isn't your thing, then great. Good for you. If you haven't ever encountered it in your job, or found a use for it because you're working on mature projects where all the main foundation and framework has already been accomplished, then fine. What people are calling you out on is the idea that because of your position and experience, anyone who did find a use for it are doing it wrong. That's arrogance.
-
@masonwheeler said in Recommendations for interview questions:
@raceprouk said in Recommendations for interview questions:
To deny you are arrogant only serves to confirm it.
Yay for witch trials! If denial of the crime can be held as evidence of the crime, how is a true innocent to defend himself?
Well, instead of being so confident about it you might say something like, "Oh, I didn't realize that's how it was coming across. What I was trying to say was..."
I mean...there's denying and there's protesting too much and there's just keep doing exactly what you've been accused of right there out in the open.
-
@masonwheeler said in Recommendations for interview questions:
...because you can trivially do it all in software instead.
Well, it's a lot harder to set up stuff like a
unique
constraint than writing "UNQ" on a whiteboard, but sure.So when designing SQL databases you grab a conference room with a projector and do it directly in the database diagram with your team?
-
@the_quiet_one said in Recommendations for interview questions:
I was going to say it's a rookie mistake for someone to come here and ask such a question, but he's been around for 3 years, so there's no excuse for his ignorance. You asked such a question here, this is what you're going to get. @theBread should have known that by now.
The question's answered. It wasn't even clear whether he was talking about code exercises or just questions.
Either way, we linked him to a thread full of code exercises and we had plenty of replies about questions, and he hasn't come back to ask any follow-ups so what's the deal?
-
@the_quiet_one The thing that I find confusing about all this talk about whiteboarding database schemas is that it sounds a whole lot like UML, which
- 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
- is almost universally considered a massive anyway, so why does anyone want to do it?
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.
-
@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.
-
@blakeyrat It was mostly tongue in cheek. No matter what, as always, topics just get derailed. We might as well have an automated function where if the system sees a topic run over 50 replies, the system just moves it to the garage.
-
@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:
-
@masonwheeler said in Recommendations for interview questions:
@the_quiet_one The thing that I find confusing about all this talk about whiteboarding database schemas is that it sounds a whole lot like UML, which
- 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
- is almost universally considered a massive anyway, so why does anyone want to do it?
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.
IME, a whiteboard is much more flexible and the handwriting is good enough when it's going along with all the talking. Collaboration is much more flexible and aside from the occasional pen running out of ink I've never seen anyone have problems with the drawing, unlike pretty much any piece of software I've ever seen.
-
Thanks for the ideas, and I knew what was going to happen when I posted the question. I was toying around with different questions, and blazing through "Tales From the Interview" to see what not to ask (so Interview 2.0 are not good questions?)
-
@djls45 I really like this one, mind if I borrow it?
-
@masonwheeler said in Recommendations for interview questions:
@the_quiet_one The thing that I find confusing about all this talk about whiteboarding database schemas is that it sounds a whole lot like UML, which
- 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
Whenever we do something like this on a computer, the minutes of the meeting inevitably go something like this:
First 15 minutes: Spending time troubleshooting the projector and its connection to the presenter's computer (or, in the case of screensharing, getting everyone to see the screen and getting their mics working).
Next 15 minutes: Getting acquainted or reacquainted with the software. This sort of thing isn't something you use on a daily basis, usually, so there's always some ramp up time just to get an idea of how the software works.
Next 3 hours, fumbling through the software. I haven't used SSMS for diagraming, so I can't speak for it, but I've used other diagramming software in the past and it's sucked balls. 90% of your effort is just getting it to do what you want it to.
Versus:
First 5 minutes: Getting everyone situated.
Next hour or so: Having people collaborate in front of a whiteboard where your only "UI" is a marker and eraser and you just hash things out without having to worry if the software is going to actually put the boxes and arrows where you intend. Every so often someone might raise their hand and ask, "What does that say next to the box on the upper left?" and the writer of it will answer, "Sorry, I scribbled that too fast, it says 'User Database'" and the author erases it and replaces it with something more legible.
- is almost universally considered a massive anyway, so why does anyone want to do it?
This thread has shown that it most definitely is not universally considered a massive wtf.
@masonwheeler said in Recommendations for interview questions:
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.Ok, so your professional experience has not shown a need for this kind of diagramming, confirming my point that just because you haven't had a case for it, it doesn't mean others are wrong for having used it in the scenarios they've tackled. You're effectively speaking as if you're an elevator mechanic, "Why on earth do you need blow torches to construct a skyscraper? I've never had to use one, and I work in skyscrapers all the time!"
-
@the_quiet_one said in Recommendations for interview questions:
Ok, so your professional experience has not shown a need for this kind of diagramming, confirming my point that just because you haven't had a case for it, it doesn't mean others are wrong for having used it in the scenarios they've tackled.
Because we're not talking about using it professionally. We're talking about using it as an interviewing tool, which I have had experience with, and it looks nothing like anything people are talking about here. 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. I pointed out that this is nonsense, because you can see the candidate's thought process just as easily (and with far less stress, irrelevance, and illegibility) by watching them write the code at a keyboard the way God intended.
Then everyone starts going off on some massive tangent about designing software and database schemas? What in the world does the one have to do with the other anyway?!?
-
@masonwheeler said in Recommendations for interview questions:
Then everyone starts going off on some massive tangent about designing software and database schemas? What in the world does the one have to do with the other anyway?!?
It's because you claimed you never did whiteboarding ever, and we were all aghast at how stupid that is.
-
@the_quiet_one said in Recommendations for interview questions:
I haven't used SSMS for diagraming, so I can't speak for it,
It's pretty great, but it's no replacement for whiteboarding.
-
@thebread said in Recommendations for interview questions:
Thanks for the ideas, and I knew what was going to happen when I posted the question. I was toying around with different questions, and blazing through "Tales From the Interview" to see what not to ask (so Interview 2.0 are not good questions?)
Brainteasers do jack to assess someone's programming or engineering skills. How does deflating your truck tires to go under a low-clearance bridge have anything to do with software engineering? The people who came up with those questions were looking for people who thought "outside the box" which OK, every so often because of unavoidable challenges you have to do on a rare occasion, but it isn't very useful for day-to-day jobs, and if it is then run away from that job as if your life depended on it.
If you want to ask some kind of challenge that requires some clever solution, then go with something that's at least in the field of programming. Because just because I know how to tell which switch operates which light switch in a box, doesn't mean I can elegantly process a binary file that switches endianness midway through without any flags beforehand informing me of it (actual problem I had to deal with in the days of yore)
-
@masonwheeler said in Recommendations for interview questions:
I pointed out that this is nonsense, because you can see the candidate's thought process just as easily (and with far less stress, irrelevance, and illegibility) by watching them write the code at a keyboard the way God intended.
no, i cannot. because i don't care about your thought process at the keyboard half as much as i care about your ability to illustrate your thought process with your team in a group think setting. sitting down and typing code is important, but not at all like the kind of thought process i want to see.
I want to see you think your way through a nasty problem that you havent had broken down into chunks for you, not code up something based on a predigested problem. i want to see you try and fail to come up with a proper solution because the problem i picked has no perfect solution, i want to see how you handle the icky part of the spec, do you notice it? if so what do you do? this is what i want to see, none of this is what i would see if i gave you a coding problem
-
@thebread said in Recommendations for interview questions:
@djls45 I really like this one, mind if I borrow it?
Not at all. I don't have any claim on it. I was the interviewee.
-
@accalia said in Recommendations for interview questions:
I want to see you think your way through a nasty problem that you havent had broken down into chunks for you, not code up something based on a predigested problem. i want to see you try and fail to come up with a proper solution because the problem i picked has no perfect solution, i want to see how you handle the icky part of the spec, do you notice it? if so what do you do? this is what i want to see, none of this is what i would see if i gave you a coding problem
I'll also point out that, since whiteboarding is more conductive to team work, if you get a few other devs in the room to collaborate with you, you get a fantastic insight as to how well they play with others.
-
@the_quiet_one said in Recommendations for interview questions:
@accalia said in Recommendations for interview questions:
I want to see you think your way through a nasty problem that you havent had broken down into chunks for you, not code up something based on a predigested problem. i want to see you try and fail to come up with a proper solution because the problem i picked has no perfect solution, i want to see how you handle the icky part of the spec, do you notice it? if so what do you do? this is what i want to see, none of this is what i would see if i gave you a coding problem
I'll also point out that, since whiteboarding is more conductive to team work, if you get a few other devs in the room to collaborate with you, you get a fantastic insight as to how well they play with others.
i do usually have several devs in the room. i give the first bit of the problem and the devs are all primed with a different "sticky wicket" of the design to bring up and are instructed to jump in and participate (while letting the interviewee retail the floor)
it's unexpected and shows colaboration. very important.
-
@masonwheeler said in Recommendations for interview questions:
"write this code/algorithm up here on the whiteboard, 'so that I can see what your thought process is like,'"
I see. You're conflating a code test with an algorithm test.
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.
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?
-
@masonwheeler said in Recommendations for interview questions:
I pointed out that this is nonsense, because you can see the candidate's thought process just as easily (and with far less stress, irrelevance, and illegibility) by watching them write the code at a keyboard the way God intended.
Yeah, I still disagree about this. Less stressful to write pseudocode on a whiteboard.
@masonwheeler said in Recommendations for interview questions:
Then everyone starts going off on some massive tangent about designing software and database schemas? What in the world does the one have to do with the other anyway?!?
Why? Hmmm....oh, yeah!
@masonwheeler said in Recommendations for interview questions:
@accalia said in Recommendations for interview questions:
You mean i shouldn't ask you as a job applicant to use a whiteboard to design a system, such as you would do in a meeting with your coworkers when you're spitballing solutions during the early phases of problem solving as a way to figure out how you approach problem solving?
There's a massive assumption in there that is completely incorrect. Never in my entire career have I done that. No one's ever even suggested it as an idea of something we would want to do.