321–330 of 565 posts
Earlier quoted context omitted.
https://trunkbaseddevelopment.com/
https://trunkbaseddevelopment.com/trunk1c.png So trunk driven development means no PRs, until you decide you want to use PRs?
Earlier quoted context omitted.
> Bonus points for no PR’s and trunk driven development as that shows a very mature team. Ugh, pass. Trunk development is fine. Skipping PRs just brings back nightmares of SVN. Even if 90% of PRs are approved without comment, it's extremely helpful for everyone to have a second set of eyes on work before it is merged in.
Where I work, development is trunk based and without pull requests, and all code is reviewed. When I want to submit code, I push it to a staging area that tracks master. This causes the commits to appear in Gerrit where (conflict-free) rebasing can be performed with a single button and the code can be reviewed. During the staging I can change anything about the commits to my hearts content. Once everyone is satisfied…
It must surely boil down to the profession aspect. Doctors and lawyers do a period of internship after and during the degree that perhaps mitigates the uncertainty around hiring. I doubt that doctors are asked to bring in a cadaver to operate on during an interview for a new position, or lawyers are asked to jump into court unprepared and defend someone as part of the hiring practice.
It sometimes seems that programming jobs need to be a calling. Ie: you spend 50 hours a week at job doing the thing but then are also asked to have a portfolio on the side that you presumably do in your spare time.
It could just be an American thing, though. Perhaps hiring is seen as very risky because sv salaries are so out of proportion to the standard across the rest of the working environment, in addition to there being very little quality control regarding professionalism in the industry that makes technical hiring such a minefield.
Earlier quoted context omitted.
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 guid…
> 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.
You literally know nothing about me, my experiences or how I conduct my life, and rather than listen to people with a different experience to yours, you choose borderline abuse.
This is the comments section of HN. Take a break and get some perspective.
Earlier quoted context omitted.
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 or…
The conversation can just as well be around a library, product or system that isn't authored or contributed to, by the interviewee.
'What architecture is used here, and what are the down and upsides in this implementation'. 'What would you do different'. 'Which part do you admire, and what don't you like'. Etc.
Earlier 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.
On average, who's going to be better at writing code, the one who has done a side coding project in the past 10 years whilst developing, or the one who hasn't but only worked a job? (assuming everything else is equal) - The one who has more time for side projects might also have more time for work, too. Unfortunately, it does remove good people, since not everything else is equal. IMHO It's still better than leet-cod…
Earlier 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.
On average, who's going to be better at writing code, the one who has done a side coding project in the past 10 years whilst developing, or the one who hasn't but only worked a job? (assuming everything else is equal) - The one who has more time for side projects might also have more time for work, too. Unfortunately, it does remove good people, since not everything else is equal. IMHO It's still better than leet-cod…
You’re clearly leading toward the former, but I could just as easily make an argument for the latter.
In my experience, people with edifying jobs (usually because the problems are harder), are less likely to need to scratch the same itch outside of work.
I think requiring side projects not only shrinks the candidate pool, but also leads to adverse selection.
I’m personally against this approach. I’m an appsec person. I absolutely do not know how to write most of the code I review. In my past two jobs I’ve been required to read code and explain it during interviews. I’ve never had trouble explaining what’s going on because on a very basic level, most languages use the same conventions. If this were a heuristic of a good developer, it would let me (not a dev) in and who kn…
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…
If you didn't have an existing code, they suggested you built something from scratch and compensated you for the time spent.
This makes a great deal of sense, to me. But I am also the type of developer that would do well at this (experienced and older). Young folks, right out of school, or with just a couple of years of experience, would not do as well. I’m pretty convinced that one of the goals of LeetCode tests is as a “young-pass filter.” It controls for people close to college age, where those types of problems are common, as well as p…
I get your point but its not like recent grads have it super easy getting their first job; you have decades of experience interviewing (part of which is Leetcode which you have probably done many times); for them it's probably the first time doing this. On top of it all many places don't want juniors at all.
I quickly learned, that if I saw a binary tree test, I might as well give up. Even if I did OK, the company was not going to give me a chance.
What I do have, is a ginormous portfolio, with dozens of repos full of ultra-high-Quality code, for shipping products, and over a decade of checkin history, along with hundreds of pages of documentation, and dozens of blog articles and postings; often directly discussing my design methods and development practice.
It has been my experience that this was dismissed, even when I curated and sent examples, directly relevant to the job.