"Here's an icky piece of code, tell me what it does and what you would do to improve it" seems to have fallen out of style, though it's not clear to me why.
Because reviewing code is easier than writing it, unfortunately.
SirNuke@kbin.social 1 year ago
Yeah, they kinda suck and they are brutal to go into cold. Having to grind a bunch of leetcode problems is a burden, particularly if you currently have a job and god forbid a family.
I would still take them over the puzzle questions that used to be popular, or the personality test nonsense that dominates most fields. At least Leetcode problems are reasonably reflective of programming skill. I'll also take them over vague open ended questions - ain't nothing more fun than trying to ramble my way into whatever answer the interviewer is secretly looking for.
Personally, when the day comes when I'm In Charge, I plan on experimenting with more day to day type evaluations. I think there's potential for things like performing a mock code review or having someone plan out a sprint based on a very detailed design document. "Here's an icky piece of code, tell me what it does and what you would do to improve it" seems to have fallen out of style, though it's not clear to me why.
That said, like it or not it's how the game is played and not changing anytime soon. Get on the Grind75 train, or don't and keep failing tech screens.
falsem@kbin.social 1 year ago
SirNuke@kbin.social 1 year ago
I disagree with that as a rule of thumb. I'll take writing 1000 lines of code from scratch every time over deciphering 1000 lines of bad code.
However, I do you think are right if limited to the ~100ish lines that fit into an hour sized block of interview time. I suspect the other half of the answer is (good) job postings have largely gotten away from hard language requirements. It's perfectly reasonable to hire someone that will need to familiarize themselves with Go or Python or Typescript or whatever. It's not fair to expect someone to analyze code in a language they haven't used on the spot.
szczuroarturo@programming.dev 1 year ago
Even deciphering 1000 good lines of code is hard . I work in abap and 95% of my time is going through old ,or very old code written in diffrent programing styles . The rest is usualy writing a one or two lines of code.
floofloof@lemmy.ca 1 year ago
Maintaining a code base is definitely harder than writing new code, in my experience.
thesmokingman@programming.dev 1 year ago
I have never found the ability to regurgitate Leetcode solutions as reflective of programming skill or even good performance. I’ve seen what talent I get from FAANG hires and what talent I get from random people with state degrees. Most of the time I will take the later. I have yet to start some crazy R&D project that actually required anything like the things Cracking the Code Interview tells you to do.
I’ve found a lot more success giving people reasonable design exercises based on company projects and code exercises related to actual work done. I have made a career of only taking jobs with similar interview processes and as I’ve grown into leadership I’ve continued to give interviews that accurately test day-to-day skills. Am I missing out on really good talent by usually ignoring FAANG resumes? So far I don’t think so and I don’t need those idiotic attitudes polluting strong, elastic teams either.
SirNuke@kbin.social 1 year ago
I see them as a flawed indicator of the ceiling of someone's theoretical computer science abilities. Having worked with some brilliant people that career shifted via bootcamps, I will content there's value in having that foundation. I also prefer Leetcode problems over having to memorize search algorithms. But yeah, it's not very reflective of day to day tasks even in R&D heavy projects. The most algorithm heavy thing I ever did was implement Ramer–Douglas–Peucker algorithm to convert points from mouse polling into a simplified line.
(There's clearly a "it's what everyone else is doing" aspect to Leetcode, on top of being very practical to run, hence I why don't see them going anywhere. They're also as objective as anything in an interview will ever be, so as I say: it can always be so much worse.)
I intend to make the hacker "dive into an icky codebase armed with a stack trace and fix a bug" aspect of software development a part of my interview process; plus lean more heavily on system design questions which is where non-entry level engineers really ought to shine. The parts that worry me are the ability to create new tests as they inevitably leak, plus whether I can truly objectively evaluate someone's performance.
I'm curious what you include and how well it works.
thesmokingman@programming.dev 1 year ago
When I was running DevOps/SRE consulting I did up to a 2hr deep dive into how to set up a codebase in VCS, establish CI/CD, design deployment, and manage the lifecycle. That gave a lot of freedom to ask specific questions related to the clients I need staff to support and also to get a feel for what people did and did not know. You start with some trivia questions and can organically move around based on the candidate to probe their strengths. That requires having a good interview team; what I’ve found is that if you train your team to interview the way you’d handle a normal design session things work out really well. I’ve got a lot of concrete problems to drop in based on real issues we’ve faced (if you’ve had to support EoL’d Ruby in k8s you can commiserate with a surprising number of folks). The length was dependent on the salary being asked for which determined title. Someone at an architect or manager level needed to know way more than someone just hitting senior status.
Now that I do general engineering stuff I’m trying to figure out something along those lines. I’m currently a fan of code reading some gnarly legacy shit we have to support and either some short data pipelining, API optimization, or component creation depending on what I’m trying to hire for. If you spend an hour with someone trying to code together you can get a decent sense of how they will work day-to-day in terms of how they handle confusion, talking through problems, and basic language knowledge. I try to remove gotchas and keep things in the candidate’s wheelhouse (One time I failed an interview because someone asked me to use a library I’d never seen and I spent an hour flailing because it needed a trailing slash but didn’t have good error messages so I could not figure out why anything wasn’t working. Huge fucking waste of everyone’s time; didn’t evaluate anything other than if I knew that library that wasn’t important.).
I don’t do take homes. I do realize that limits the candidate pool to people that are comfortable collaborating in a potentially stressful situation. I sometimes worry about that. It’s very important for a strong remote team to work well together even when things are awkward or stressful, so there’s a bit of value doing it that way imo.
Frankly I don’t care about interview questions leaking. Coming out of DevOps, it’s very obvious when someone actually understands what’s going on in the interview and when they’re copying and pasting. I’m very happy to have people take code from Stack Overflow during interviews; that’s real fucking life and shows me their research skills. Candidates I will hire can explain or improve the code. I’ve had to reject plenty of sysadmins that do not understand any of what they’re copying and cannot adapt to minor changes that I’ll add just to see how someone handles it. I worked at a company whose questions were on Glassdoor. We had plenty of people that came in prepared for those. We hired several that could roll with the punches (what if you change the inputs, how do you test this case, what’s going to break) and dropped plenty that clearly had no fucking clue.
falsem@kbin.social 1 year ago
Why are you assuming FAANG resumes can't do system design?
thesmokingman@programming.dev 1 year ago
I have two problems with FAANG candidates.
First, having gone through the full interview process at several and rejected all due to laughably low base salaries, I know how those candidates are selected. The skills being evaluated have fuck all to do with what I’ve actually needed engineers to do. That gives me zero confidence in their ability to do anything meaningful. Solving tic-tac-toe doesn’t mean you can actually walk your way through security problems in an API.
Second, the toxic cultures at these companies is not something I want infecting my teams. Google, for example, is famously about making yourself look really fucking good for a performance review board, not making the company better. Amazon makes people think the talent pool is big enough for perpetual unregretted attrition and pits peer against peer. Meta completely strips any semblance of ethics and therefore customer understanding. Twitter doesn’t fucking care about security.
Most engineers meet expectations. Period. People think FAANG is hot shit. It’s not. It’s arguably worse than most run-of-the-mill places because people on the internet like to make FAANG out to be hot shit. The chances of someone actually doing something big at FAANG are so fucking tiny it’s just like thinking you’re going to make the next killer indie game.
Drusas@kbin.social 1 year ago
It's pretty shitty that you are attributing the cultures of companies to the personalities of individuals. You're going to miss out on a lot of good people doing that.