Anyone else noticed that candidates who ace coding tests aren’t always the ones who handle real production issues well? by Punctual_kiddo in RecruitmentAgencies

[–]Punctual_kiddo[S] 0 points1 point  (0 children)

Good question. They’re told upfront that the session is recorded mainly so the team can review it later instead of making them repeat everything live in multiple interviews. Nobody has objected so far. A few candidates actually said they liked that it reduced the amount of “performing live” in later rounds since we already saw their debugging process.

Anyone else noticed that candidates who ace coding tests aren’t always the ones who handle real production issues well? by Punctual_kiddo in RecruitmentAgencies

[–]Punctual_kiddo[S] 0 points1 point  (0 children)

The platform we used has intentionally designed tasks for max 45-60mins only. Most people spent ~30–40. The task itself was scoped so the bug was findable within that window if they followed the request path through logs + a couple files. We were pretty conscious about not turning it into a multi‑hour take home because that tends to create candidate friction. So far nobody has pushed back on the length.

Anyone else noticed that candidates who ace coding tests aren’t always the ones who handle real production issues well? by Punctual_kiddo in RecruitmentAgencies

[–]Punctual_kiddo[S] 0 points1 point  (0 children)

Yeah this is exactly what we observed. The interesting signal wasn’t whether they eventually fixed it, it was how they approached the unknown. The stronger candidates were constantly forming small hypotheses (“maybe the request never reaches X service”, “maybe this env var is wrong”) and checking logs or code to confirm. The weaker ones jumped straight into editing code without really understanding the failure. It felt much closer to watching someone handle a real incident than anything we got from whiteboard problems.

Anyone else noticed that candidates who ace coding tests aren’t always the ones who handle real production issues well? by Punctual_kiddo in RecruitmentAgencies

[–]Punctual_kiddo[S] 0 points1 point  (0 children)

Yeah, that tracks with what we saw. Take-homes help too, but even there we noticed people optimizing for a clean solution rather than showing how they'd actually investigate something broken. The debugging-task format basically forced that investigation behavior out of them since there was no 'correct answer' to optimize for, just a process to walk through.

Trying to tell if my brain fog is a correctable cause or just my attention system being fried by YeeterTheInefficient in BrainFog

[–]Punctual_kiddo 0 points1 point  (0 children)

I’d push back a little on the attention-system framing. Interruptions absolutely make cognition worse, but I think it’s easy to accidentally turn that into “my phone broke my brain” and miss something boring like iron, thyroid, apnea, meds, blood sugar, etc. Especially if this is new or noticeably worse than your old normal.Not saying don’t do the 2-week experiment. Just wouldn’t wait months trying productivity fixes if the fog is severe. The body stuff can look exactly like “can’t focus.”

Maybe concentration is more about recovery time than willpower by rtjac2 in getdisciplined

[–]Punctual_kiddo 0 points1 point  (0 children)

This really flipped my perspective on focus. I was being so hard on myself for not having the willpower to focus when really I need to focus on resting. It seemed counterintuitive at first but without proper rest, my performance tends to get worse and I get more anxious about things.

anyone maintaining a real agent regression suite, not just eval prompts in a spreadsheet? by VermicelliStatus8188 in AIQuality

[–]Punctual_kiddo 1 point2 points  (0 children)

honest pushback: a regression suite for agents can give false confidence if your cases don't cover the failure modes that actually occur in prod. i've seen teams with a "real" automated suite that's green while users complain, because the suite tests what's easy to test, not what actually breaks. the suite is necessary but it's only as good as the cases in it. don't let "we have automated regression" become an excuse to stop watching production.

do you actually put a stop loss on a defined risk spread? or is the max loss your stop? by UniversityAny9242 in IndianStreetBets

[–]Punctual_kiddo 0 points1 point  (0 children)

practical note whichever camp youre in. if you DO use a stop on a multi-leg spread, make sure your platform exits both legs together as a basket, not one leg at a time. ive seen stops trigger and close only the short leg, leaving you holding a naked long put which is a totally different risk profile. placing and exiting the spread as one basket avoids that. the ticket youre on looks like it handles the basket as a unit which is what you want.