Lets see: We have GitHub, and GitHub Enterprise Server, and a GitHub API. Then there's the command line and a desktop version, and one that is just browser based I guess. Then you have different pricing plans, Free, Team, and Enterprise? How is Enterprise different than GitHub Enterprise Server? It's very easy to find evidence to confirm our bias.
Claude code is actually one of the most straightforward products I've used as far as onboarding goes. You download the tool, and follow the instructions. You can use one of the 3 plans, and everything else is automatic. You can figure out token usage and what models and versions to use and how to use MCP servers and all of that -- there's a lot of power -- but you don't need to do ANY of that to get started trying it out.
You're not being:
> That critic who doesn't try the stuff he criticizes
You're being:
> That critic who is trying to confirm their biases
Definitely not a prompt and pray type thing, though you can do that if you choose. It shows its work, in the newest version there's three modes (planning, executing, auto accepting edits). You can also hit Esc at any time to redirect as you see it going in the wrong direction.
> In every place I’ve worked, outside of independent contracting, the sales person didn’t do the trench work.
Have you ever worked at a place where the sales people promised features that didn't exist? A bad sales person can ensure you're in the trenches doing work that is urgent but not important. A good sales person anticipates requirements, identifies when they're not currently available, and proactively works with the right people to get the important features prioritized strategically.
The sales people talk to the customers, so from a certain perspective they're the ones in the trenches and talking to customers while you're in the back office plugging away at a keyboard.
The first time I had the plug pulled on a public API a product I worked on used sucked pretty bad. At this point its happened to me so many times that its just another line item of business risks thats an inevitability. I've never worked at a company that failed to recover as a result. Then again, I've never worked at a company whose entire business hinged on one single API.
The likelihood of things breaking or behaving in unexpected ways are data points I think about when assessing risk irrespective of whether an API is public or not. In some industries even the public APIs are more risky than using the unofficial Venmo API likely is.
> Anyone who's ever had to work on a system that had copious unit tests deep within will know the pain of not just changing code to fix a bug, but having to change a half-dozen tests because your function interfaces have now changed and a healthy selection of your tests refuse to run anymore.
In my experience this problem tends to be caused by heavily mocking things out more so than the unit tests themselves. Mocking things out can be a useful tool with its own set of downsides, but should not be treated as a requirement for unit tests. Tight coupling in your codebase can also cause this, but in that case I would say the unit tests are highlighting a problem and not themselves a problem.
Perhaps you're talking about some other aspect of unit tests? If that's the case then I'd love to hear more.
I'd also add to this that people often end up with very different ideas of what a unit test is, which confuses things further. I've seen people who write separate tests for each function in their codebase, with the idea that each function is technically a unit that needs to be tested, and that's a sure-fire way to run into tightly-coupled tests.
In my experience, the better approach is to step back and find the longer-living units that are going to remain consistent across the whole codebase. For example, I might have written a `File` class that itself uses a few different classes, methods, and functions in its implementation - a `Stats` class for the mtime, ctime, etc values; a `FileBuilder` class for choosing options when opening the file, etc. If all of that implementation is only used in the `File` class, then I can write my tests only at the `File` level and treat the rest kind of like implementation details.
It may be that it's difficult to test these implementation details just from the `File` level - to me that's usually a sign that my abstraction isn't working very well and I need to fix it. Maybe the difficult-to-test part should actually be a dependency of the class that gets injected in, or maybe I've chosen the wrong abstraction level and I need to rearchitect things to expose the difficult-to-test part more cleanly. But the goal here isn't to create an architecture so that the tests are possible, the goal is to create an architecture that's well-modularised, and these systems are usually easier to test as well.
There's an argument that this isn't a unit test any more - it's an integration test, because it's testing that the different parts of the `File` class's implementation work together properly. My gut feeling is that the distinction between unit and integration is useless, and trying to decide whether this is one or the other is a pointless endeavour. I am testing a unit either way. Whether that unit calls other units internally should be an implementation detail to my tests. Hell, it's an implementation detail whether or not the unit connects to a real database or uses a real filesystem or whatever - as long as I can test the entirety of the unit in a self-contained way, I've got something that I can treat like a unit test.
As with all music recommendation engines, I want the ability to remove things from the mix. I have zero interest in music similar to Kidz Bop, it's just something I happen to play for my kids.
Interviewers tend to have one of two different mentalities...
Some are trying to see you fail. They're looking for a reason to say "no". They tend to not be of any help on a problem, will often try to find ways to trick you. They also tend to have an ego problem -- you need to prove to them that you're worthy of joining the team.
The other class of interviewers are those that want you to succeed. They will answer questions, and help clarify things. Even if you are unqualified for the role, and they know it, they still want to help you along so they can see your best work. People that shut down when they get nervous tend to open up to these interviewers. They also tend to be the people that are more pleasant to work with.
>Even if you are unqualified for the role, and they know it, they still want to help you along so they can see your best work
So ~14 years ago - after about a year at Microsoft, I was encouraged to assist with interviewing new candidates. At that time, there was no official guide/rulebook for interviewing, but I was told unofficially;
"We hire people with a solid technical base, who may not know EVERY thing at the time of interview, because we really want to hire on their future potential".
"If a candidate is doing poorly, don't be rude - if they asked where they failed, tell them - because, they may very well interview again in 6-months, and if they show a significant improvement, they may well get hired then."
"Any technology they list on their resume is 'fair game' - they had better know it, and if you have direct experience in a niche technology that they list, grill them to see if they are being 'honest'"
And - we were often paired with other technical interviewers, and everyone kept detailed notes. A single veto by any interviewer during any of the multiple phone sessions (and/or eventual in-person interviews) would end that stage of the process for that candidate.
It worked well - I interviewed more than one person who didn't make the cut in the first round of tech screen calls, but 8-months later - they did - and ended-up being very valuable members of our group.
However - there were definately other interviewers that were basically trying to trick the candidate at every step of the process - they were not some of our better team members and honestly, should not have been involved in interviewing.
"Any technology they list on their resume is 'fair game' - they had better know it, and if you have direct experience in a niche technology that they list, grill them to see if they are being 'honest'"
Such a strange stance for MS to take (IMHO). I've got 20+ years experience in lots of different languages and different technologies. I've been looking for a new job and have been brushing up on skills for interviewing. I just don't think it's possible for me to be ready to be grilled by a current expert on 15+ languages that I've shipped high quality, production code. The flip side is to only list the three I can take a grilling on today on my resume? It seems like a pretty short sighted approach. Maybe they have moved on in this stance?
Grilling may not be the best word there, but if you say you worked with language X, I think it makes sense to give you some questions about it to gauge how good you are with it. Some people stuff the resume by mentioning every language that they did for a toy project once in college, and then we don't want them to be put in charge of the project which requires deep knowledge of the same language. Better to find it out in advance. That doesn't necessary means that candidate will fail and not be hired - just maybe not for the project that requires the knowledge they don't have.
Having done plenty of interviews, it's surprising how many candidates list every technology they may have touched for the briefest of moments. For me, "grilling" someone on something like a programming language is about determining if they've _really_ used it or not.
If a candidate lists multiple languages on their resume, I'll often ask them to do a compare and contrast -- what do they think are the strengths and weaknesses of the languages? What did you use language X for? Do you think language Y would have been better/worse/same to attack the same problem?
I'm not looking to trip them up, just find out if their resume is an accurate reflection of their experience.
"I used it so I wouldn't need to rewrite the 300 proprietary internal libraries and dependencies our company also paid to write and maintain in that language" is probably a valid answer for many BigCo employees.
I just had an interview with MS, they seem to have a far better approach these days.
I was surprised that they approached me because the team works primarily in C# and Go, and I've been doing JVM languages mainly, and only a small amount of Go, but the interviewer emphasised that they want people who can learn and enjoy learning.
They then asked me to choose a language I know well and describe a strength and weakness of it.
Interviews exist in this weird space disconnected from the reality of the work and being judged by those closest to the work. Not many real on-the-job situations would require someone, for example, to be able to recall the protocol number for a given protocol without looking it up, yet that's one of the questions that a particular very famous tech company has their recruiters ask, and you get auto-rejected for not knowing. It's unfortunate when a place becomes so large and so desirable that they'd rather force people to try multiple times to get through an arbitrary obstacle course and succeed on some combination of chance and skill vs attempting to more honestly assess if a given candidate could actually succeed in the role they're hiring for.
I hate 'trivia' interviews with 'gotcha' questions dealing with experiences their team may have recently dealt with (and probably took weeks to identify/resolve).
I would say the port/protocol memorization may be required depending on what job you are interviewing for. If its for a tech support job, maybe the ports/protocol question is pointless.
I have no respect for such people. Not because of their lack of "niceness", but because that kind of behaviour betrays a lack of technical confidence.
That remark isn't just about interviewers; it applies to all colleagues. More generally, I tend to respect people who are smart enough to know what they don't know, and honest enough to admit it.
> behaviour betrays a lack of technical confidence.
Yes agreed. I've seen this in interviewing and in teaching. People who are insecure make it about how smart they are, people who are confident make it about helping others.
In a former role, I got the opportunity to be on the interviewer side of the table.
I considered it a privilege to have the potential to influence progress in someone else's career.
I am very much in the latter category of wanting to see folks succeed.
We had one candidate that didn't have experience in the particular technology we were interviewing for, but I could tell he was highly intelligent, just very nervous.
I asked him questions on another complex technology that he'd listed on his resume, to try and draw out some of his thinking on his problem solving skills.
He did great.
I suggested to him that he should come to us with questions, and interview us as much as we were interviewing him. I wanted to see him get the job.
He didn't… at first.
The others on the panel didn't give him their vote. We'd picked someone else that ended up flaking out.
I went back and tried to make the case that we should extend him an offer.
They ended up doing so… dude was an absolute ROCKSTAR.
Please be the one that wants people to succeed. Interviewing is hard, people.
> The other class of interviewers are those that want you to succeed. They will answer questions, and help clarify things. Even if you are unqualified for the role, and they know it, they still want to help you along so they can see your best work.
That's how I go about it. Even unprepared candidates can return someday with more experience/knowledge, or apply to a different position where they can succeed - or letting their friends/acquaintances know about the role.
Also, as we can see in this post, a bad interview experience can really taint a company's image, which can to some degree prevent people from applying
Nonsense. Misleading people is hardly ever the right or long term beneficial approach. If the candidate is insufficiently experienced, skilled or prepared then it's not wrong to let them know (they might actually appreciate to learn why they don't get the job). This doesn't have to be done in an impolite way though.
a) I think as interviews as auditions rather than exams.
b) I try to find someone's edges, so that the hiring manager has better information. In other words, if I were to give a candidate full marks, I've probably failed as interviewer.
but is a traditional database cryptographically secure? if a super user with write permissions (or, say, direct access to the physical data store) modifies records are users able to validate the integrity of the data?
The difference is that client applications does not need to trust proper "append-only" permissions were enforced on server side but they will be have the chance to detect any tampering while in the former approach, it won't be noticeable
same thing you said but in a different context... sir, this is a hackernews