Threads for redblackbit
-
If the candidate spends too little time on the requirements, it means they are less senior than you expected.
This is the kind of stuff that I’m not a fan of when it comes to interviews. Maybe instead of someone not being senior, they just recently had an interview where they tried to find out more requirements and were marked down for it because it seemed like they didn’t understand. Or maybe, they think they are getting a signal from the interviewer that they should move on. Or maybe, they just solve problems in a different way from you. Maybe they like to start sketching things out and asking questions along the way.
I’ve had job interviews (even ones I ultimately got, at the level I wanted) where people used exactly these sorts of things to decide that I wasn’t as senior as they wanted. I’ve seen it happen to others as well. Interviews are complex, nerve-racking social endeavors. Processes that assume all qualified candidates ought to do things the same way or that there are definitive signs that a candidate is less senior are going to miss out on many good candidates and instead select for people who think like the interviewer.
In general, I think it is much better to look to understand the person you are interviewing, not grade them. See how they approach things. See what things they like and what things they don’t. Find out how they approach software development and learn from it. There is no one size fits all evaluation criteria.
-
You make some valid points, thanks for the thoughtful response :)
Taking a single sentence out of context makes it look like there is a recipe that needs to be followed to the letter - that wasn’t what the post was trying to convey. But, I can see how the way some sentences were phrased could have given that impression.
In my opinion, if you are asked to solve a vague problem, asking clarifying questions is a sign of maturity. That doesn’t mean that the questions need to be asked right after hearing the problem, or that you can’t sketch something from the start.
There is no universal recipe, and most importantly, there are no grades. The goal is to get a sense of the candidate’s experience and problem-solving skills while working with them like you would with a coworker.
-
I’m glad to hear that you don’t feel there is a recipe. :) I have met many people who do feel that. I will say that I can’t help be see that in your article.
It’s a positive sign if they also do some back of the envelope estimations to get a feeling of the scale required.
You can tell a lot about a candidate’s experience by how quickly they can spot failure modes and come up with elegant ways to solve them.
You might not even have to ask much as an experienced candidate will highlight failure modes as they go, and find ways to mitigate them
A seasoned engineer should know the core building blocks like the back of their hands.
I know these may seem trivial. In fact, they may seem like just obvious things that more senior candidates ought to do. But I think they focus on how we ourselves solve problems and don’t think about others approaches. Take the first one, I never do back of the envelope estimations in an interview. So while of course that won’t be the end of anything, I won’t get those positive marks. Why don’t I do them in an interview? I have dyslexia and in stressful situations I switch numbers quite a lot, so I avoid doing that.
I am perhaps harping on nothing and I admit as much. You’ve already said you don’t feel that there is a one sizes fits all solution. I just have seen so many talented engineers turned aside because their approach was different. I worry that sometimes we don’t even realize we are doing these things.
Maybe they aren’t quick to highlight failure modes. Maybe they ruminate on things for a while. Maybe they have a bad memory for terms but are great at concepts. So when you start discussing dns or consistency models in the interview they sound like they aren’t familiar with them, but do actually understand them when applied. Or maybe you just asked the question in a way they weren’t familiar with and they are now just confused.
I will say, I think you do capture the sort of thing I’m getting at very well in this sentence.
Take the time to understand whether that’s really the case, or whether they instinctively skipped over a basic small-scale design and went straight to the point.
This is exactly the sort of thinking I think is important. Understanding how this person thinks and how they approach problems in a way that can help you as a team/company. I personally don’t think that there is anyway at the end of an interview that you can answer the four questions you start the post with. This is what I mean by grading them. We can change from grade to the word you use, assess. I don’t think an interview should be an assessment. I think it is about coming to understand that engineer, understand what things they care about, what things they are passionate about, what things they like and don’t like, what sort of systems they’ve worked on, what sorts of problems do they enjoy, what sorts of values do they have the code they write.
I think understanding these things is much more important and much more valuable than assessing how senior they are.
-
-
-
Hey nice tricks you’ve got there! I appreciate the concrete examples. The units in the first equation should be “bps” though, and the Little’s Law section seems to have mixups with variable names.
-
Whoops, thanks for the correction! :)
-
Thanks for putting this together. The rule of 72 is going to come in handy.
While we’re doing suggestions - the queueing example with actual numbers plugged in swaps lambda and W. While still mathematically correct it did caused me to stutter for a sec reading the example since it looked like a super slow rate of entry and an insanely huge processing time.
-
-
-
Your written steps for the handshake are wrong. It’s SYN, SYN/ACK, ACK like the picture shows.
-
Whoops, thanks!
-
I have been using Obsidian to keep track of what I learn, and it has been working great for me so far. I love the fact that I can quickly link concepts together without too much hassle.
+1 for Obsidian. I like that it’s all local, and in plain markdown. I setup a small script to automatically checkin changes to a git repo, for syncing.