201–210 of 282 posts
I'm aware this exists, but I'll admit to not having read it directly. (HR gives me a list of questions I'm allowed to ask in an interview and they tell me those questions are based on research but I only have their word they are)
> It’s easy for the candidate to self-assess their own progress.⊕ When the candidate isn’t doing well on it, they probably already knew it without needing to be told as much by the recruiter. This is a much better candidate experience than the whiplash of thinking you solved a question perfectly only to realize that the interviewer was looking for something else entirely. Not to say that I think this is a bad type of…
"We don't want you to know you've already failed so we can waste your time for a month in the off-chance nobody better shows up."
If someone fails my interview, it is completely possible that they’ll still get an offer. I have one data point, and my colleagues are going to collect more. I’ve changed my vote from no to yes in debriefs many times once I saw other feedback. But that’s a lot less likely to happen if my interview wrecks their confidence.
At one place there was a bug squash interview like this. Rough idea was we wrote a very small version of a system we had in our app (some data-syncing-then-displaying service), with a handful of bugs and a very simple feature request. It was very helpful for sanity checking if a person was able to be in front of a computer. There's a bit of a challenge because I think there's a pretty low ceiling of performance (stra…
They don't need to be deep to be useful. I once used it on nodejs on a hunch, looking for anything that felt "off", and discovered it was accessing settings files I had no idea even existed. Turned out the other dev was having problems because of one in his home directory the rest of us didn't have.
Earlier quoted context omitted.
I administered bug squash questions a few dozen times. Experience definitely trumped the smartest, most prepared young programmers, because no matter how much they studied, they hadn't really faced a real test suite in a large codebase. We had to rate them on a different scale, because otherwise very few of them passed.
why do young programmers need to pass? nobody gives a shit whether experienced people pass leetcode so give me one good reason why you should rate young programmers differently.
Earlier quoted context omitted.
Great idea, that's exactly what I like to do as well. Because many people were interested in some actual code, here is an example that we used for Java: --- public class UserDao { private Provider sessionProvider; public UserDao() { this.sessionProvider = new DbSessionProvider(); } public boolean saveUser(User user, ApiConfig config) { try { Session session = sessionProvider.get(); session.save(user); System.out.prin…
This code looks like normal enterprise Java ugliness to me - I object to it on principle, but apart from having to pass ApiConfig when saving a user I probably wouldn't identify any of the official problems you listed without familiarity with the rest of the codebase.
It's not a bug ("this" is implied, so it works just fine), but leaving it out hints to me that it was originally a third argument to "saveUser()", and either the original person writing this didn't have a solid API in mind or "saveUser()" was intended to also be static like "EmailUtil.sendEmail()" and it was switched around later on. Overall hints towards two conflicting styles in the same codebase and no good guidelines. Or maybe there are such guidelines (as hinted in the "solution"), and whoever updated this class only did it partway. This is the point where I'd poke around in the repo history to see why it's like this and whether anything should be changed further in either direction.
Earlier quoted context omitted.
> Booleans are not canonical Java as return value What should you return instead? Or should the method return void and raise an exception on failure?
Probably boolean. If you don't see the difference, welcome to Java :D
Earlier quoted context omitted.
This code looks like normal enterprise Java ugliness to me - I object to it on principle, but apart from having to pass ApiConfig when saving a user I probably wouldn't identify any of the official problems you listed without familiarity with the rest of the codebase.
Same here... and funny enough the only thing that really looks wrong to me is they used "this" in only one of the two places they used "sessionProvider". It's not a bug ("this" is implied, so it works just fine), but leaving it out hints to me that it was originally a third argument to "saveUser()", and either the original person writing this didn't have a solid API in mind or "saveUser()" was intended to also be sta…
Given the Java code in question, while I understand the idea that "well, the session provider may just be hard coded" and such, I would definitely want to hear something about deficient exception handling. It's obviously an important part of the code and while I may not be able to spew out the exact correct exception handling without knowing more about the context and what exceptions may occur, it is obviously very wrong as written.
Earlier quoted context omitted.
There’s no chance that I can come up with a good bug story on demand without any preparation.
compare this with the technical interview bomb of demanding you write a full blown program right fuking now, complete with tests. Which one do you prefer?
Earlier quoted context omitted.
Per letter, capitalization doesn't take much longer, but over the course of an entire sentence or paragraph, having to reach for shift can potentially add up. Sure, it's still small overall, but I think it's reasonable to give the benefit of the doubt to a stranger about whether the extra effort for them to type them is more than the amount of extra effort for you to read it.
It doesn't take longer for me as I have both of my hands on my keyboard and I can hold the Shift without any delay (or noticeable delay), simultaneously. You could even use "caps lock" in which case you wouldn't have to use shift at all.