231–240 of 286 posts
The arrogance most software "engineers" have is astounding. 99% of companies aren't splitting the atom. Companies shoot themselves in the foot and waste so much talent this way.
I consider myself a mediocre, if competent, programmer. I would like to improve my level of code reviews, but I'm on an operations team and I'm pretty much the only person who programs (it's a small company for now, but if we're successful, we'll grow pretty dramatically over the next few years). What tips would you have for doing this?
If you can get access to review work by folks on other teams that do more coding, that would be a good start.
From there, you need to allocate time to looking at changes closely. Don't just accept things at face value. Ask basic questions like "why is that there?" and "what does that really mean?" and hunt the answers down. Code consistency can mean many things, formatting and variable casing are the obvious things, but also things like how method names are constructed (e.g. when do you use "get" vs "fetch" as a prefix), are concepts named consistently (is "business hours" always spelled "business hours" adjusted for casing or is it called things like "hours" or "biz hrs" in some places.
I look for three big things: * technical soundness - does the code do what it says it does? * ontological soundness - are the concepts used well defined with clear boundaries and do they play well with the conceptual framework of the rest of the application? * semantic soundness - is the meaning evident? does the code do what you'd expect? How hard is it to reason about what the code does when it is called?
I view writing code as a primarily communicative activity. So, I evaluate it based on how well the ideas it embodies are structured and how well it communicates those ideas.
Earlier quoted context omitted.
Doing the background check after the offer is fine, it's insane that they do it after the candidate already starts the new job. So what, I leave my current job to come work for you, and in the first week you tell me "sorry you failed our background check" and let me go? Who the F would ever agree to this kind of risk? >>8. End of first week, we occasionally have to let someone go on background issues Yeah, that's bon…
We're not talking like government security clearance here. If you have some major legal or financial issue in your life then maybe it depends what exactly the BGC turns up or how it's adjudicated. If not, there's basically zero chance it's going to affect anything. Just a formality from the candidate's perspective.
Earlier quoted context omitted.
Exactly. A lot can unexpectedly go wrong during a background check, some companies ask employees for (very old) W2's they may not have, etc. There was a time when I worked at and a new co-worker suddenly disappeared without a trace, and I was told in confidence by a VP they "were not who they said they were" which I presume means they failed a background check. This was during growing pains, they were probably doing…
If an employer ever asked for an old W-2 I'd refuse, and if it was enough of a problem I'd recuse myself. That's private, sorry. Not that it would matter for me personally, I've been self employed for 15 years. But still there has to be some self respect.
Earlier quoted context omitted.
I wonder where you find developers desperate enough to accept such conditions - I'm not sure I'd want to work with them.
This has never been a problem, except when someone is currently employed and is leaving a job to take one at our company. Right now, there's a lot of really good talent that does not have this issue.
And in that case you do the check before they start with you, yes?
We use this process, and it has helped us hire some great developers without having to use third party staffing and headhunters: 1. Post well written job post on major job boards. 2. Immediately reply via text to every applicant (yes, we have opt in on the application) 3. Initial screening including several knock-out questions via text. Immediately let candidate know if they are not selected and why. 4. 30 minute can…
>5. Interview and code review session. Bring a side project, show us how it works. So you are filtering out candidates that have families or lives outside of work that do not spend their free time coding?
Earlier quoted context omitted.
Honestly, being "willing to grind" might be a good thing to target if it's a good proxy for being willing to do the work . However, I agree with the general sentiment that almost nobody is doing the research to ensure their interview process selects for the things they actually want.
I’m willing to grind if you present me with a real life problem you need solving. I’m not willing to run on a hamster wheel, it seems illogical to me.
People are forgetting why companies these days do Leetcode in the first place. The initial reason why we have Leetcode today is that Google originally determined through their interview research that the smartest candidates were the ones who were best at algorithms. Google wanted to hire the smartest people, not necessarily the best coders, so that’s why their interviews were mostly algorithmic. Of course everyone st…
How do they measure which candidates are the smartest? And if such a method exists why they don't use this method in interviews directly?
Earlier quoted context omitted.
If an employer ever asked for an old W-2 I'd refuse, and if it was enough of a problem I'd recuse myself. That's private, sorry. Not that it would matter for me personally, I've been self employed for 15 years. But still there has to be some self respect.
Unfortunately these types of requests come after you have presumably accepted the offer and declined alternative offers...
I also decline signing NDA, providing data they should not request. Asking to cross off anything that encroaches intellectual property I might create after hours.
But if I would need that paycheck ASAP all of it goes to trash and I would comply to most of shenanigans, maybe not all but still.
> Bug hunter > Intentionally introduce some logical flaw or defect and see if a candidate can spot it. A good idea is to go back and find recent bugs that were solved and pull the source before the fix was applied. Can the candidate identify the root cause? How would the candidate suggest resolving the defect? I've had this exact idea on the back-burner for years! https://news.ycombinator.com/item?id=18794465 The exa…
I had a bug hunt as part of an interview once (or, I should say, once that I remember). It was different from that proposal in that the code was not part of the company's actual codebase - it was entirely fabricated for the test. It was fun, though; I enjoyed that more than livecoding and live-whiteboarding.
We cloned a repo, ran they tests, it failed, and the task was to identify why it failed.
It was a tough process for me, since I've never really used Python debugging tools, so I actually had to learn during the interview, but I was able to reason well and picked things up quickly enough that I found the cause, and we had time to discuss ways it could have been fixed.
It was different. I do well during Leetcode questions, so stepping out of that framework was uncomfortable and stressful. I got an offer, but I felt like it was closer than it should have been.