> 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
> is probably one request in a long queue of requests that team is dealing with
You've explained away the crux of the problem without even identifying it as a problem. Queues are an inappropriate construct for managing work. If something urgent & important takes weeks to even get looked at then there is a prioritization problem. If something that isn't urgent or important even gets worked on at all then there is a commitment problem. Based on what OP has described, the company is likely doing a lot of work they shouldn't be doing and working on things in the wrong order. Similarly, the work OP is doing may be much less important than they think it is.
Now, I agree that it's important to understand how the system works, but IMO it's equally as important to understand how it can be improved. Long lead times is definitely not a good thing, and also not a foregone conclusion at big companies.
The queue can be WSJF-t and still be long. Crux of the problem is OPs issue might not be as important as OP thinks.
Now if there are too many people waiting on the central team and all requests are valid the company should address the single point of failure. Grow the central team, train more externals to become contributors or agree to have duplication to a certain agree. Not everything is worth a platform with today's tools and (SaaS) services.
Who said OP's task was particularly urgent or important? Maybe it's getting pushed down the list because they don't have a prioritization problem. We don't know - all we have is OP's (limited) perspective.
> Queues are an inappropriate construct for managing work.
I disagree. A queue is used to assign priority to a project. When there is more work than people to do the work, you need to prioritize and triage. Just because there is a queue doesn't mean that you can't handle urgent work. You can move it to the head of a queue.
Usually what accompanies a queue is a ticketing system. Nobody like these, but when the organization reaches a certain size, you need this. Tickets are good because it forces the requesting party to put down in writing what they want. This is a necessary step to ensure that right work is done, and it leaves and audit trail, for future people to see what decisions were made and what work was done.
I've worked in an organization where we used a stack based method. In that case the most important thing was the last request. This isn't a good way to work, because it's hard/impossible to maintain focus.
> Based on what OP has described, the company is likely doing a lot of work they shouldn't be doing and working on things in the wrong order.
How can OP, as an engineer, or anyone else, that just joined a much bigger organisation, have any clue that a company is doing work that they shouldn't be doing AND they are doing it in a wrong order?!
Good leadership that sets clear direction and initiatives followed by good middle management that takes these initiatives and disseminates it into something relevant and actionable by the teams doing the work. If you're lacking this then its worth trying to ask for this information to help inform your decisions.
For the record I fully acknowledge that this may not be possible and they very well may need to work within the system in a less-than-optimal state. Understanding the root of the problems help you navigate and ideally enact change even if it's more localized.
OP was commenting on why there may not necessarily be a causation, and you commented on how the doctors tend to think there's a correlation. It just as well could be that schizophrenia tends to lead to increased marijuana consumption as people are self medicating. I'm no expert, so I don't have any strong beliefs around causation, but I do think both lines of thought (marijuana causing schizophrenia, or vice versa) seem pretty logical to me.
It's pretty widely believed that there is a correlation between the two, but the reason behind the link is where there's a lot of debate.
Unless they're self hosting, this might even be a super easy thing to add. With AWS and many other cloud providers this is either the default or a simple checkbox.
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.