It's kind of funny hearing both potential employers and employees coming up with "concise" or good enough code example. I think this exactly the beauty of this approach. If you don't talk about some simple sorting Algo code is always full of tradeoffs. Talking about these tradeoffs how your potential hire thinks about them if they even see them. This is the real value of this approach I think.
When hiring developers, have the candidate read existing code
291–300 of 565 posts
Re: When hiring developers, have the candidate read existing code
#292Earlier 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…
I would not use trunk based development as indicator of mature team. As you write there is much more to it and one can only see through it after joining company. For me trunk based development alone would be indicator that company is immature and does not even know they can have a process.
It's the opposite. Few companies know that you can do without PR. Even fewer know why they are doing PR or where it comes from. But everybody starts with PR, it's the default in their VCS UI.
Re: When hiring developers, have the candidate read existing code
#293I'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…
Surely this will filter out ~50% of people who are good but don’t have any public code? I have a family and as such no free time for coding so I haven’t written any code I can legally show anyone else in more than a decade. But everyone who has employed me is more than happy with my work. Not to mention code is only half of why you would want to employ any developer.
I agree. I would be happy to provide references of the developers and engineers in my ex-teams, whether collaborators or mentees, who would give me glowing references.
Instead, I'm asked for senior-managers/directors as references... who were the reason why I left in the first place. I guess HR just wants to know I was actually employed there (tick box)
Re: When hiring developers, have the candidate read existing code
#294Earlier quoted context omitted.
Care to elaborate on why your experience tells you this? I’ve put this into practice numerous times with positive effect, so my more relevant experience tells me this is a winning strategy, compared to in line docs, which are objectively worse in nearly every way.
I think I gave one example: if the doc includes the rationale for the value, it needs to be updated. But your more relevant experience tells you that’s wrong. I really don’t understand such aversion to a one or two line comment, but let’s just not work together in the future. ;)
I explicitly said not to write “why” docs to explain specific value choices, but rather document the context around the setting, and what happens when the value is raised or lowered, and why you might want to do that, so I’m thinking this isn’t a topic you’re grasping very well.
You’ll be fairly lonely if you reject working with everyone who’s read Clean Code, and truly alone if you won’t work with anyone who understands something better than you.
Re: When hiring developers, have the candidate read existing code
#295Earlier quoted context omitted.
It's neither faster nor better, in practice. It's not faster because you can just name the variable whatever it is the value represents, so by adding a second descriptor (the comment) you're introducing needless complexity. It's not better because you really shouldn't be changing a value you don't understand the context around, which means reading much more than a one-line comment.
I am saying things like this: https://github.com/golang/go/blob/master/src/cmd/cgo/ast.go#... belong in the source code, not a Why doc. No variable naming can give that context.
If you think variable naming is the only tool in the “self documenting code” toolbox, I recommend learning substantially more before dismissing the concept.
Re: When hiring developers, have the candidate read existing code
#296Earlier quoted context omitted.
> I’m sorry you had such bad experience but you were working with the wrong people (feels like toxic even). It's the tool itself and it's imposed workflow of blocking work and gaining absolute power in demanding changes, that causes the working environment to become toxic. Nobody would ever do that in a meeting "I'm blocking this work now until my demands have been met". That would be incredibly hostile, but with thi…
It doesn’t have to be like this. Even when I was CTO, I’d submit my code in a PR and my team would pull me up on mistakes and inconsistencies. It was really annoying! And also great. PRs are a great way for the whole team to learn about how the organisation cuts code, and can reduce the number of errors, but of course with poor leadership they can be used for evil.
> It doesn’t have to be like this. Even when I was CTO, I’d submit my code in a PR and my team would pull me up on mistakes and inconsistencies. It was really annoying! And also great.
I can imagine that you had fun mingling with the commoners for a day, now try it on all of your actual work, and with the whole C-level team gang up on you for each review.
> about how the organisation cuts code
You don't have any guidelines for how the organisation cuts code, and that's why you like the review process, because it covers up for that.
Re: When hiring developers, have the candidate read existing code
#297Earlier quoted context omitted.
I am out. My good code are paid for and thus is owned by someone who is not me and can't be shared with a third party. The code that own is inherently bad as I want to create things as fast as possible without being bogged down by proper code writing etiquette.
Everyone in this thread seems to be hung up on sharing code from an employer or 'good code'. You could clone an open source repo and use that if you're worried. The value isn't the code; it's the conversation. "Bring your own code" is just meant to put the interviewee at ease because they are already prepared to talk about their own code.
> You could clone an open source repo and use that if you're worried. The value isn't the code; it's the conversation.
Open Source code plagiarism is a major problem and doing random forks/clone of popular repos to up your github cred is a thing and in my opinion it is unethical. Even if the interviewee tells you it is an open source project you will have a hard time distinguishing their code and the code from the original repo.
I think the interviewer should show their own production code and ask the interviewee what they think and what suggestion they have to offer. If you are not comfortable showing your own production code ask the interviewee to explore an open source codebase.
The "Show me what you got" approach puts way too much unjust pressure on a candidate and might force them to chose unethical means just to impress you. Then again if you want be impressed and if it is working so far for you, ignore my whole argument.
Re: When hiring developers, have the candidate read existing code
#298I hope it's actually to an ide. They do so much to make code easier to read, like showing the code highlighting, function docs, and links to the source
Re: When hiring developers, have the candidate read existing code
#299I'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…
Sounds significantly worse then whiteboarding.
Re: When hiring developers, have the candidate read existing code
#300Earlier quoted context omitted.
That's one way to look at it. Another might be that if you write code that passes unsanitised input to anything and can get that code through testing and review then maybe you're not the kind of organisation that a candidate who knows about security wants to work for. In the end this is still a language lawyer question. It's a technicality that should never be relevant. If it is you've already gone wrong several time…
Many protocols read values of a network to specify how much is left in the packet (it's how packet boundaries are usually encoded, specifically in SMB1/2/3). So yes, no matter how paranoid you are you're eventually going to have to pass that value to something in your code :-).
Many protocols read values of a network to specify how much is left in the packet (it's how packet boundaries are usually encoded, specifically in SMB1/2/3).
Sure. So do many other protocols and file formats. But if you're using those values for memory allocation without checking them first then getting a 0 might be the least of your worries. Unchecked large values might be a DoS attack waiting to happen.
If you work with C code where security is a factor then surely you already know this so it still seems odd to put so much emphasis on your original question. You do you I guess. :-)