Why delete the comment? Useful context for stochastic_monk's reply is missing now. You could always preserve the existing and possibly incorrect comment and append an "Update" or "Edit" section to the comment to override your earlier comment.
982 karma · joined July 7, 2016
What if I never see a critical log because the trained model decided that it is unimportant? How is such a situation generally solved in the industry?
How widespread commonmark really is? Any popular sites using it? If I write my blog posts in commonmark is it safe to assume site generation tools 10 years from now will correctly render commonmark?
We can refute whichever post we want to. If you don't like it, read another post.
Consider that the parent comment author might already be making pull requests to the projects of his interest. The snarky "PRs welcome" is therefore unnecessary and unwelcome. Everyone here knows PRs are welcome in an open source project. Some of us do send PRs. But whether someone sends PRs or not has no bearing on whether one can appreciate or criticize an idea as long as it is done in a substantive manner.
In fact, whether the parent comment author sends PRs or not is orthogonal to his complaint that we have too many build systems that is increasing the burden on users and maintainers. If you have something to say against this point, please do so on its own merit in a substantive manner without insinuations or ad-hominem attacks.
Isn't this already so in most Linux distributions like Debian and its derivatives, RHEL and its derivatives, etc.?
Regarding the question about culture, yes, busy people often get sloppy. But when a P1 alert comes because a site reliability engineer could not resolve the issue by following the playbook, it looks bad on the team and a lot of questions are asked by all affected stakeholders (when a service goes down in Amazon it may affect multiple other teams) about why the playbook was deficient. Nobody wants to be in a situation like this. In fact, no developer wants to be woken up at 2 a.m. because a service went down and the issue could not be fixed by the on-call SRE. So it is in their interest to write good and detailed playbooks.
Therefore, just to offer a counterpoint, I would like to register my experience here. A random name surely did not do the trick for us. Simple tricks like creating a random hidden field would be broken by spambots in less than 48 hours. It took a great deal of expensive WAFs like Barracuda and a lot of Lua scripting combined with cookie analysis (and overall request header analysis) to detect spambots with only a 90%-95% accuracy and keep them out.
I am quite lucky to have worked in companies where the peers and management encourage debates and arguments and do not take it as a sign of incompetence.
I had no idea there were companies that would take perfectly reasonable questions on a broken process as a sign of incompetence. Thank you for enlightening me. I now know to be careful enough to avoid such organizations in future.
> We ended up embedding these dashboard within Confluence runbooks/playbooks followed by diagnosing/triaging, resolving, and escalation information. We also ended up associating these runbooks/playbooks with the alerts and had the links outputted into the operational chat along with the alert in question so people could easily follow it back.
When I used to work for Amazon, as a developer, I was required to write a playbook for every microservice I developed. The playbook had to be so detailed that, in theory, any site reliability engineer, who has no knowledge of the service should be able to read the playbook and perform the following activities:
- Understand what the service does.
- Learn all the curl commands to run to test each service component in isolation and see which ones are not behaving as expected.
- Learn how to connect to the actual physical/virtual/cloud systems that keep the service running.
- Learn which log files to check for evidence of problems.
- Learn which configuration files to edit.
- Learn how to restart the service.
- Learn how to rollback the service to an earlier known good version.
- Learn resolution to common issues seen earlier.
- Perform a checklist of activities to be performed to ensure all components are in good health.
- Find out which development team of ours to page if the issue remains unresolved.
It took a lot of documentation and excellent organization of such documentation to keep the services up and running.
Are there any web-application-firewall level spambot filtering that would ensure that the bot traffic can be continually monitored and the rules to block spambots can be continually updated?
One should be able to devise a solution to a simple problem like this without any CS course at all.
For example, the correct answer does not appear in the list of available options, or where the problem statement is not precise enough to solve in an unambiguous manner.
There is no human I can talk to and ask clarifying questions to resolve the ambiguity because, you know, it is a HackerRank test!
After going through these experiences, I have decided that HackerRank test is just not worth the time. As a rule, I decline any request to take a HackerRank test citing my reasons as politely as possible. Surprisingly, more often than not, the recruiter is happy to setup a telephone round where I can talk to an actual human.
It's not a matter of fear or offense. It's a matter of judiciously investing my time on the right opportunities.
I get about 3 to 4 calls from recruiters everyday. If I agree to go through this kind of interviewing process every day (even if the bar is low), I would be spending more than 20 hours every week just doing HackerRank tests. This is not feasible for me. Therefore just like the recruiters need a way to filter candidates out, I need a way to filter recruiters out.
Requesting a HackerRank test is just one of the many filters I use.
No more extreme than suggesting that someone who raises thoughtful questions on a broken hiring process must certainly be a bad fit for an organization.
> Sorry, I don't want to work with a bunch of pedants.
Now, this is taking it to an extreme!
Looks like it is a difference in culture that I am used to and the one that you are used to.
At my workplace, it is perfectly acceptable for someone to suggest a complete change to our CI/CD process. In fact, we have changed our complete CI/CD process twice (SVN/build scripts -> Mercurial/Jenkins -> Git/Travis-CI) already with minimal loss in productivity because someone questioned the existing CI/CD process and suggested a well thought plan to switch to a new one.
But I get your point that sometimes it may not be feasible to carry our such a drastic change in process, infrastructure, etc. But suggesting such a change is going to be acceptable and we refusing to accept such a suggestion is also going to be perfectly acceptable and both this person and us working in harmony even after this disagreement is also going to be acceptable.
HackerRank test can be as standard or as non-standard, and as easy or as difficult as the individual employer wishes it to be.
Reversing a string takes 2 minutes or less even if all you know is how to work with strings and how to write a for-loop.
I have never been in a startup that fears arguments. Every startup I have been a part of has lively debates and arguments almost every other day. It's only the large slow moving corporate giants where I see such lack of debate and arguments on what is obviously wrong.
I would go to the extent of saying that a startup that does not encourage arguments in a harmonious fashion would die very soon anyway. Debates and arguments help in weeding out stupid ideas and focus on what that really matters.
This person's email shows that he can have a qualitative argument in a coherent, polite, and non-confrontational fashion - exactly the kind of people you need in startups!
I don't know about you, but I would not want to hire someone who can take any task and complete with minimal issues. Where I work, one is encouraged to argue about what is not right in the meetings and offer better solutions.
This candidate is doing exactly that: Argue why a certain hiring methodology is not effective and what a better alternative is. Considering that this candidate does not just follow orders but challenges the status quo and the fact that he has volunteering-based projects to show makes this author very likely a good fit for my organization.
A week or month from now, the new owner of the domain sets up a HTTPs website. With the old certificate I have, I can now launch an MITM attack on the new owner for about 2-3 months!
What is preventing us from making domain name governance and registration completely decentralized?
What is the "This" you are referring to when you say "This is not how it works".
Also what kind of modern workplace are you talking about? I am working in a place that is developing software in the year 2018. I guess that is fairly modern. I see both effective and ineffective managers in this same workplace. What exactly is your point?