241–250 of 565 posts
Earlier quoted context omitted.
I do that extensively when hiring and it is valuable. But sadly, many people can hold a technical discussion without actually being able to read/write code. I'd like my orchestra to have a lively discussion of music theory, but I still need to hear them play the violin.
I agree it's not a straightforward thing - it's just that in many cases people seem to be hiring a violist but screening them with live sessions of Guitar Hero.
Like not sure how many times I need to revers a linked list IRL. Never would be my guess.
I just stop the process if I get a Leet code link. Timed and IDE in the browser.
I still remember getting a c++ question that had the answer "press ctrl + z" to stop the process. 12 years of c++ not once did the embedded device have a keyboard.
Earlier quoted context omitted.
A lot of developers' best work is within employers' proprietary code bases, do you consider it a red flag when they share some of that code with you?
It should be. As should “bring your own code”. In which other engineering industry can you ask this of people?
Earlier quoted context omitted.
Skipping pr’s is not equal to skipping code review. If you pair, there’s two sets of eyes, to commit both pairs have to sign a commit. You can also organise a demo/quick mob session before commit. Then there’s a level of trust in your teammates. PR’s are great for open source projects as act as gatekeeper so not everyone can commit freely. If you need to gate keep your team members then I’d question the strength of y…
> If you need to gate keep your team members then I’d question the strength of your team. I'm sorry, what? Review is a gate for everyone , and is a sign of basic project maturity. WebKit, Mozilla, Chrome, LLVM, Linux, etc are all review gated projects. No change is landed - can be landed - without review. If you're questioning the strength of those teams I cannot imagine what your team would need to have on it??
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…
A lot of developers' best work is within employers' proprietary code bases, do you consider it a red flag when they share some of that code with you?
Earlier quoted context omitted.
A lot of developers' best work is within employers' proprietary code bases, do you consider it a red flag when they share some of that code with you?
It should be. As should “bring your own code”. In which other engineering industry can you ask this of people?
I think that's leaning to interrogation, and less of interviewing.
Earlier quoted context omitted.
It should be. As should “bring your own code”. In which other engineering industry can you ask this of people?
Art, architecture, writing, music, I mean pretty much every creative industry.
I sometimes ask candidates "what kind of interview do you feel would best bring out your strengths?" and try to adapt the interview to their response if I can. It's helpful if they want to talk about side projects or war stories, but doesn't pressure them to. I still give my coding challenge after. Wonder why no one else does this.
When hiring at scale we value consistency so this wouldn't work well. However in my company we started an initiative called "candidate experience". In one of the interviews we allocate some time for the candidate to "flex" as you put it. We ask open ended questions such as "what is your proudest achievement?" or "is there anything you wanted to tell us but didn't had a chance to?". These questions are not used to eva…
> gives a chance for the candidate to ... put forward their best self.
How does that work? If it genuinely won't be evaluated, what's the point of getting their best self? How do you make sure things you learn in this don't affect your judgement later?
Earlier quoted context omitted.
Skipping pr’s is not equal to skipping code review. If you pair, there’s two sets of eyes, to commit both pairs have to sign a commit. You can also organise a demo/quick mob session before commit. Then there’s a level of trust in your teammates. PR’s are great for open source projects as act as gatekeeper so not everyone can commit freely. If you need to gate keep your team members then I’d question the strength of y…
> PR’s are great for open source projects as act as gatekeeper so not everyone can commit freely Yeah exactly, PR's are based on the fact that you have some person who is the owner that have complete power, and many other contributors who have zero power and whose contributions will mostly be rejected. You simply don't have that situation in a company, where everyone is an owner on equal terms, and all contributions…