541–550 of 565 posts
Earlier quoted context omitted.
https://trunkbaseddevelopment.com/
Okay now I'm wondering what the alternative is, because this just looks like "development" to me.
Earlier quoted context omitted.
The point is to start with something open ended, so the candidate can talk as much as they want on the subject, broadly, and then, based on what they say and what they don't say, I narrow in on particulars: "Are you aware of any differences in dialect between the SQL of MySQL and the SQL of PostGres?" It's not like they lost points for the stuff they didn't know, I simply wanted to be sure I understood the limits of…
You might want to consider if there’s a way to discover that without triggering the candidate’s imposter syndrome. Your script above reads like Tom Cruise trying to get Colonel Jessup to admit he ordered the code red. All that’s missing is the candidate breaking at the end and screaming “YOU’RE DAMN RIGHT I DON’T KNOW HOW TO DEBUG SQL”.
* If they don't know how to debug SQL, I'd like to know that.
* Do they simply say they don't know, or do they try to bluff? Are they confident about what they don't know? Like I said in a different comment in this thread, one of my greatest hires ever was a former teacher who was very confident about what she didn't know -- she never felt any need to bluff.
Given two people of exactly equal skill, if one bluffs and the other is confident enough to say "I don't know", then I'll hire the one who says "I don't know." Because then when we are actually working together, I know they will be honest with me whenever they need help, they won't be trying to keep secrets from me.
Also, about this:
"triggering the candidate’s imposter syndrome"
Given two people of exactly equal skill, if one has imposter syndrome and another doesn't, I'll take the one who doesn't have the imposter syndrome. Or put differently, given two people of exactly equal technical skill, if one demonstrates a higher emotional intelligence, I'll hire that person.
Earlier quoted context omitted.
Code reviews are incredibly valuable, and are a crucial part of software development at all of tech companies. I would argue that if you aren't doing code review, then you're saying that you believe you and all your company's engineers are better than the engineers at Google, Apple, Mozilla, Microsoft, Oracle, ....
Having engineers better than the average employee at those companies is a lower bar than you'd imagine. Smaller companies can pay much more (in expectation), and can simply poach the cream of the crop (who are invariably frustrated by useless process and corporate politics) from the big ones. On top of that, most development processes are designed to minimize the blast radius of underperforming engineers, so your act…
Having engineers better than the competent engineers that are responsible for the dreaded process at the FAANGs, MS, etc is hard. The review policies of big projects tend to have been hard learned, and dismissing them because "they're useless process" is a poor choice.
Earlier quoted context omitted.
But why would you use such a remote asynchronous late stage feedback loop, if you are literally sitting in the same room as your collaborators, during the whole development process?
> if you are literally sitting in the same room as your collaborators Your very premise is wrong. At any sufficiently large company, you are unlikely to be sitting in the same room as every collaborator and stakeholder, or even proxies for them. As a simple example, the team I currently work on (on one project of several) is 10 people across 8 US cities in all four US mainland timezones, and the stakeholders and coll…
Earlier quoted context omitted.
How do they differ?
They're actually good. Though the size and risk of a project do materially matter. If chrome ships a bug, that'll cause an impact on billions of people potentially, where as the typical software bug will impact a few hundred or dozens of people?
The way you get any project to be "actually good" is by adopting methods to ratchet quality. Early WebKit did not have the same strict rules it has today, and we suffered because of that. Introducing review + test for every change rule was introduced, and the frequency of regressions dropped dramatically.
I've interviewed maybe 500 engineers in my career. I'm an early engineer of Instacart, 3rd engineer of Eventbrite, founding engineer of Reforge. Started 3 companies myself. My interview is always the same: 1. Bring code you've written 2. Share your screen 3. Explain what it does and I will casually ask questions about it You get so much information from this: - How they think about code - If they think it could be be…
Earlier quoted context omitted.
Do you ensure your clean commits all pass all CI tests?
I use the same workflow as NateEag and mdavidn. My preference is: • All commits SHOULD pass all CI tests • Merge commits MUST pass all CI tests The reason I don't require every commit to pass all tests is to maximize reviewability and logical consistency of commits. For example, if a file needs to move, and then be modified slightly to function in its new location, I prefer to break that into two commits: 1. A verbat…
Earlier quoted context omitted.
Do you ensure your clean commits all pass all CI tests?
I use the same workflow as NateEag and mdavidn. My preference is: • All commits SHOULD pass all CI tests • Merge commits MUST pass all CI tests The reason I don't require every commit to pass all tests is to maximize reviewability and logical consistency of commits. For example, if a file needs to move, and then be modified slightly to function in its new location, I prefer to break that into two commits: 1. A verbat…
My one big tip: One vice that I see among hiring managers is an unwillingness to ask tough follow-up questions. If you ask a question and there is any vagueness in the answer, you need to drill down deep until all vagueness is eliminated, so you understand exactly what the person knows. Follow up on what's said, but also follow up on what is not said. Here’s a real-life example. I asked a recent applicant (for a full…
The premise here is good, but instead of asking the same question again and again, I would rather supply more and more information until I get the answer I am looking for. (and jot down what prompting was required to get that answer) I agree with the sibling comment, otherwise this becomes a guess what I am thinking exercise.
My one big tip: One vice that I see among hiring managers is an unwillingness to ask tough follow-up questions. If you ask a question and there is any vagueness in the answer, you need to drill down deep until all vagueness is eliminated, so you understand exactly what the person knows. Follow up on what's said, but also follow up on what is not said. Here’s a real-life example. I asked a recent applicant (for a full…
If you wanted to check if they can write a query than ask them to create a simple select or insert statement. The drilling down turned the interview into a hostile conversation. Easily ways to test that skill.