Follow

Creating a list of job interview questions, I try to determine how I would answer them in an interview... and some of them are just difficult, even at (or because of) my level of expertise. I keep trying to figure out, if this question feels awkward to answer for me, how can I make it less awkward for the candidate and still learn what I want to know. This is hard to do.

· · Web · 1 · 0 · 1

@CarlCravens For my job, I had a list of technical questions along with specific instances that we have encountered that would have required knowledge to avoid the bug. I just picked low, medium, and high level of skill versions.

Sadly, I have yet to encounter someone who can answer any of them. Well, besides myself, I know of four others but those are hard people to find in the job process.

... then we got a new manager who told me they were too hard for the applicants to solve it and to stop

@CarlCravens Yet, for some reason, all the new hires after that all kept making the same basic mistakes time and time again.

@dmoonfire @CarlCravens

Keep the questions but preface them with, "I don't expect you to get all of these so don't worry if some are too hard."

(Actually, I know *nothing* about interviewing. Honestly, there should be courses and training and industry-wide practical guides on the subject just like there is for Scrum or C#.)

@suetanvil @CarlCravens I completely agree on the training. Most of what I picked up came from when I was working with a industrial psychological assessment company (fancy word for a former lie detector company that specializes in job interviews for low-paying jobs) and the phrase "good judgement comes from experience, experience comes form poor judgement". :)

Though, as a C# programmer, I do have a tendency to ding people for case-sensitive typos and wrong words in their resumes.

@suetanvil @CarlCravens Also my first 4-6 questions are easy throwaways just to get a baseline on how the applicant responds, in an attempt to figure them out and also to help them relax.

@dmoonfire Those questions can be useful if they dig into how the applicant thinks... even if they don't get the answer, if they were on the right track for how to _learn_ how to solve it, that's good enough for me. I want to know if they can learn to manage our environment. Questions specific to your environment that you expect a specific and complete answer to are basically trick questions... they depend on the applicant having specific experience and recalling it out of context.

@dmoonfire But the interesting thing about my initial toot is that it's not technical questions I'm coming up with... it's behavioral stuff. "Tell me about a time you had to deal with a problem outside your skill set. How did you deal with it and what was the outcome?" That one's not really uncomfortable. But "Tell me about a time you found an assignment to be challenging and how you overcame that challenge," can be a problem for junior-level in an unchallenging job. (cont...)

@dmoonfire How do I explore how they respond to a challenging situation if they've never experienced one? That's the real tricky part. Is there a way I can change that question to get the info I want from someone who can't think of a time they were challenged by their work?

@CarlCravens That's why the level of the job and expectations becomes important. I mean, I wouldn't expect a junior C# coder to know how garbage collection generation is important but I would expect them to know a value type verses a reference.

(Related to the trick question, knowing how value types are stored in memory was the question because someone blew our stack by thinking `struct` for everything! in a recursive call).

@CarlCravens The problem with "explain a challenging" is that even a so-called senior coder can really be just someone who has coded a long time but hasn't really been challenged.

That's the crux of my problem. Most applicants don't want to say "here is how I fucked up an entire company for a weekend" because that seems bad. Or their "challenging" problem is watching someone else solve it but not understanding of the "why" it was a problem.

@dmoonfire Exactly so... I expect people to be applying for this job _because_ their current job isn't challenging. So I want an applicant to be comfortable saying that, and to turn it on it's head... "I feel my job isn't challenging and I'm looking for a job that will push me to learn more and become better at managing Linux." That, at least, tells me something.

@CarlCravens They want to improve themselves so I consider that a positive sign. But they also don't have the skills (yet), so that's where I start delving into how they solve problems (to see if they think to document, how to search, how to bisect the problem).

But most don't think about the related items (unit tests, docs, verification, positive/negative) because those are less in the path of a problem.

@dmoonfire Oh, very... that's part of my challenge. As a senior systems engineer (25+ years) I pretty much have only been asked to interview senior-level candidates. Now I'm staffing a NOC and the target skill set is mostly junior level and I'm having to reset my expectations.

@CarlCravens Yeah, I *love* *love* interviewing high level people (~34 years for me) because you can ask really detailed questions and they will usually tell you that they don't know it, but the following searching would work.

With lower levels, I find I have to try identifying *how* they would go about the problem and (for me) how much they pay attention to details. Google is everywhere, no one has everything memorized, but I consider "I don't know, but a search on SO for 'x y z'" is good.

@dmoonfire This is why I find "write me a bubble-sort" interviews so dumb... I can look up how to do a bubble sort on wikipedia, and I don't need to do even that because all my languages have a sort() function of some kind already. How to do a bubble-sort is just asking if they've memorized a bunch of unnecessary information.
My favorite prof was the guy who did open-book tests, because "if you use it every day, you'll know it; if you don't, you can look it up." And that was before Google.

@CarlCravens And the live coding isn't really helpful for the some reason.

"Yay, he can write a simple code with some Google search."

We already know it takes six months average to get into our code base (I annoy my managers by actually tracking that), so any interview question isn't going reflect that.

I just don't have a good method for finding what I want, baring running a full-blown RPG with a scenario related to our code. :)

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!