timv

If I'm unemployed, then full day is fine. If I'm really keen to get out of my current job, or really keen to work for you, then I might do it. But if I'm just exploring opportunities, or I have other options in progress, then I'm not taking a day off just to interview.

With any interview when it might be really obvious 10 minutes in that it's not going to work. If I've scheduled that during my lunch break, or for an hour before/after work, then that's a small cost.

If I take a day off work to interview, then that's costing me in the order of $1000. If I don't know whether I want to work for you, then why would I do it? And I definitely can't do that for 5-10 different roles that I might apply for.

A full day is also quite hard work. Interviews are stressful. Dealing with people you don't know, trying to make sure you don't do/say something stupid, it gets exhausting.

I generally expect 4-6 hours worth of interviews before an offer, but the typical process stretches those over a few weeks, which allows the candidate to fit them into available blocks of free time, and gives the candidate oppotunities to think about how things went, what questions to ask, whether this seems like the right fit, and pull out at any point.

It used to say > he told me he didn't complain

They're different. The original article definitely read like

I decide to turn the lights off in a shared office without checking with anyone else, but my office-mate assures me that he wasn't the one who ratted me out

- It presumed that the existing spreadsheet would be flawless and bug-free. That is almost never the case; ad-hoc spreadsheets are often riddled with mistakes.

- It presumed that it would be a high risk/expensive task to replicate that spreadsheet in a technology that was more suitable for the job. Yet (if you assume that the spreadsheet was essentially correct in its function) it is one of the simplest implementations - you have a working specification for the behaviour you're implementing. If you are not confident in your ability to replicate a working spreadsheet, and then test that your new code behaves identically, then what are you going to be confident to build?

- It presumed that the technology used to automate the spreadsheet would replicate its behaviour faithfully. But that's only true if you use the same underlying application, so you'd only get the benefits if you automated Excel. If you used Open/LibreOffice, or Apache POI, or something similar then you still have all the risks that come with a reimplementation.

- It failed to account for the operational complexity of such a solution. Automating a spreadsheet is fragile. The resulting system would likely be a nightmare to operate.

- It failed to account for the long term maintenance cost of running a suite of business applications that are cobbled together from bits-and-pieces without any planning or cohesion. In that environment you should assume that an application will be in service for 7-10 years with the possibility of it running for 20 or more years. One of the biggest ongoing costs for that team was the number of bespoke applications we had, each using esoteric technologies and inconsistent design approaches. For example, a project to upgrade the underlying Operating System (or web browser, or database, or ...) would need to test each of those apps and potentially fix bugs. Which meant finding the source code, working out how to build it and package it, etc. Not to mention the cost of trying to stay on top of security patches for the underlying components and libraries. Consistency has massive value in that sort of environment.

You learn those lessons from experience - if your experience has been in a similar sort of working environment. I don't presume that every senior engineer has that same set of experiences and will agree on the same set of priorities and tradeoffs. But if I'm hiring you and paying a senior engineer salary because you have experience, then it needs to be experience that is applicable to the sorts of problems we face and the decisions we need to make.

From your intro, my guess was that this would be a senior/junior mis-match. With 10 years of experience, employers will think of you as someone who should be a senior engineer, and they are likely to be evaluation you based on that expectation. That might be your expectation too - you didn't really say what sort of roles you were applying for, but if you're applying to "senior engineer" roles, then each company will have an implicit set of expectations about what a senior engineer can do. Some of those expectation might be made explicit in the role description, but many won't be. The role might talk about "mentoring junior developers" but there's an implicit expectation about the content of that mentoring - you have to know certain things in order to be able to teach others about them.

Those expectations will vary by company, and even by hiring manager. Some interviewers will think "A senior Java engineer must know spring+hibernate", but if you've spent your career working in the Hadoop ecosystem, then that's not likely to be true. Or "A senior engineer must understand the trade-offs of unit-testing vs integration-testing" (and be able to give the answer that they want to hear) but that's a question that is more relevant for certain project types, and not every engineer is going to have an opinion on that.

A likely problem here is that your 10 years of experience haven't given you the right set of skills to be able to answer their interview questions in ways that satisfy their (probably unreliable) interview filter. Maybe you really don't have those skills, or maybe you have them in some form, but not in a way that matches the interviewer's expectations.

Some time ago, when I was hiring into a medium/large bank, my expectations for a 10+ year engineer would be that you could be given a loosely defined problem, work your way through the details to understand the real task to be solved, design a solution (typically changes to be made to an existing system), implement and unit test that solution, assist in developing a system testing plan, assit in implementation, and understand the implications for support/operations. Each of those steps has a bunch of further detail that varies greatly by workplace, and interviews have "right answers" that assume you've done this enough times under similar enough conditions to be able to reach the same conclusions as they've reached.

As an anecdotal example. I remember hiring for a particular role, and one of the questions proposed a scenario where a particular business function was currently being driven from a spreadsheet, but they had outgrown that, and wanted to automate more of the workflow, and wanted to run a project to build a web-based internal system for that. How would you approach that? One of the candidates said something along the lines of "If they have a working spreadsheet, then I wouldn't want to change that. There's lots of risk in reimplementing it, so I would look at tools that could be used to put a web front end on top of the spreadsheet, and automate it that way." That was the wrong answer. It was a valid answer, and they explained why they wanted to take that approach, and "because risks" is somewhat reasonable, that team was not big on risk-taking. But whatever that candidate's experiences had been, they had led him to propose a solution that didn't fit with our expectations, and made what we considered to be the wrong trade-offs (and he persisted with that proposal even when we prompted him to go in a different direction). It's quite possible that some other company would say "Yes, that's exactly what we wanted to hear, you're hired!", but he wasn't the right person for us.

So - what's the solution?

You might try angling for a less senior role. It's hard when you have seemingly relevant engineering experience, to pitch yourself as a mid-level engineer, but you might need to find a way to do it. Then the expectations are lowered, you can get in the door, find out where your previous experience was leading you astray, and then be promoted to a senior role (or switch to a new company, now that you have the skills you need for the interview). You might need to trim your resume in the process so that you only mention the last 5 years of experience, and don't look too senior.

Alternatively, it might just be an interviewing issue. You might just need to translate what you do know from "small company" to "big company". Try something like https://interviewing.io/ and learn how to explain the skills you do have, in terms that big companies like.

--

edit: s/prompted/promoted

Kotlin basically has the Java type system with a few extensions, but no substational changes.

Ceylon has its own type system that draws heavily from the FP/ADT style of thinking. It's not OCaml (nor does it want to be), but it's also not Kotlin.

Like @paxys (sibling comment), I've not seen it be a problem once you're in, but it does affect the ease with which you get job offers, and those can be a big part of career growth.

Sometimes you land a great job, in a great company, with a great manager and you work your way up, with the right opportunities at the right times with the right rewards.

But most people find that they run into a blocker somewhere along the way. Maybe the company isn't growing fast enough to create relevant oppportunities. Maybe you get a manager who sees you as irreplaceable and doesn't want you to move up. Maybe something stuffs up and the blame falls on you and your promotions get stalled for a while.

And in all those cases (and more) it helps to have a ticket out of there. Even with 5 to 10 years of experience, some % of hiring managers / recruiters will look at where you got your degree (and in what discipline) and take that into account when deciding whether to interview you. And fewer interviews leads to fewer offers, leads to fewer choices, leads to less control over your career path.

The lack of a degree is not a total blocker - once you get into that first role and prove yourself you've got good chances - but it will have some impact and could make it harder to meet your goals.

The OSM Wiki contains a Data Catalogue for Australia. https://wiki.openstreetmap.org/wiki/Australian_Data_Catalogu...

The issue right now is that both the PSMA data (that you want OSM to use) and the ASGS data (that you infer it is using - and in some cases that might be the source of the boundaries that were entered, but it is not officially in use by OSM) are licensed under CC-BY, which is not 100% compatible with the ODbL that OSM uses.

The necessary solution is to request an explicit waiver from the data provider, which has been requested for PSMA, but (as far as I know) never received a response.

It's also easy to get blinkered, and deceive yourself into thinking that the company will be successful despite the warning signs that those outside the company might see.

I worked at a bank during the GFC. And it was easy to believe (perhaps correctly, but that's irrelevant) that we weren't really in that much trouble. We were solvent, we were diversified, we weren't exposed to sub-prime, etc. But the market took a beating to us. And it didn't feel like that was justified. But that simply didn't matter. The stock was in free fall, and even if we were right and the market was "wrong", the market is always right because that's what sets the value. If you could afford to take a long term view, then the price recovered, and it wasn't the end of the world (though there were definitely better performing investment options). But I had colleagues who were leveraged against company stock and were getting margin calls every second day.

Which brings me to my second reason for hating to hold stock in my employer - those colleagues couldn't sell their stock due to insider trading rules. They had to find the money for the margin call, because the fact that they had "much more information and market insight" (as you put it) actually meant they weren't allowed to sell. Holding (public) stock in your employer is a big risk because even if you see the price crumbling, you may not be able to get out, and you just have to take the hit.

What areas are you looking at.

If they've taken outside investment based on a business plan of scaling, then it doesn't matter whether they want to scale. They either need to do it, or hand it over to someone who will.

I love nicely sized companies that are profitable and long term viable without the need to chasing after constant growth, but you only get to do that if the investors agreed to it. That's much easier when the investors are just the founders.

So if you're reducing the number of staff employed to support "system A", but you have vacant positions supporting "system B", then you you need to offer those positions to any affected staff, or show why those employees would not capable of doing the new job.

Or they didn't have to fire anyone - it's not like China actually gets to see employment records for random staff in Omaha.

Sadly, many Java dependencies are quite deplorable.

Elasticsearch is stateful, it's essentially useless if you don't have some form of persistent storage for it, because its purpose is to act as a datastore. So we make no attempts to treat the Elasticsearch containers as if they're stateless in the "no permanent storage" sense, but you can point your Elasticsearch data directory to a mounted volume and keep that state away from the core image.

But having an immutable image is a bigger deal. The expectation that users have of docker images is that you don't need to edit anything on the image files themselves, but that the configuration is provided from an external source, typically through environment variables.

Installing X-Pack is an image change. It stores new files in the plugins, bin, and config directories of Elasticsearch, and will typically require changes to your main cofiguration file. That's something docker users generally don't want.

Installing a license is a state change. The license is loaded with an HTTP API, and we store that data in the data directory alongside the stored documents. So for most users it's not a violation of their "immutable" expectations.

The other expectation is that you can simply start the container, and run it to completion and then terminate it - you don't want a process that expects to be started, and then reconfigured, and then restarted, etc. That affects other aspects of how you can configure Elasticsearch, but doesn't impact the licensing issue quite so much.

> They introduced X-Pack by bundling it with the default distribution as a time-limited trial without explicitly stating that it is just a demo.

I assume you're referring to the Elastic docker images, as I believe that's the only place where we've ever bundled X-Pack without any explicit opt-in (Our windows installer also includes X-Pack, but it's clearly marked as an optional & commercial component).

We totally underestimated the confusion and difficulties that would cause, and it was fixed with the 6.0 release.

The difficult was balancing the different needs of different users, with the constraints of how docker containers are typically managed. X-Pack requires a file-system level install, which is not something that docker users expect or want - an image should be built once and then be essentially immutable. No one likes to have to enter the container in order to install a new plugin.

Since it was possible to disable X-Pack functionality, or install a free license for a subset of the features, it seemed like shipping the container with X-Pack pre-installed and letting users dial it back as needed, was the better option compare with shipping without X-Pack and forcing customers to reconfigure their container so that they could get the features that they needed.

We didn't expect that there would be so many users for whom Docker was the primary/initial point of contact with our stack. We believed that we would be mostly working with users who already understood what X-Pack was and what they were getting. When it became clear that that wasn't true, we had to come up with a solution, which is what we shipped in the 6.0 release. We didn't want to change the behaviour in a minor release and cause more confusion for users who were relying on X-Pack being installed, so it wasn't simply a case of changing the way the images.

The X-Pack licensing code was built on the premise that X-Pack was a plugin the was explicitly installed so that those who installed it would know what was going on. And when it was written, that was true. One of the consequences of that assumption was that it would automatically generate a trial license on start-up, and then you could install your own purchased license after the fact. In order to offer Docker containers that worked the way users would expect, we had to make changes to that so that X-Pack could be installed, but default to only enabling the free features, so since 6.0 we are now able to provide 3 different docker "flavours" - pure open source, basic (free license), platinum (trial license for paid features).

We do want people to use X-Pack. We believe that the free (basic license) features offer something useful that users should know about, and the success of the company relies on users knowing that our commercial features exist, and being able to evaluate them and decide if that's something they want to purchase. But the docker situation was never intended to be a "bait-and-switch", it was just a problem that caught us by surprise and took some time to rectify.

For historical accuracy, the inclusion of X-Pack in our docker images was not the introduction of X-Pack, it had been available for quite a long time before that and the underlying commercial IP was several years old before we started publishing Docker images.

I'm defending roadmaps because I believe that any plan with future dates counts as a roadmap, and because such things are essential to any sort of cross unit coordination.

If the DB team says "I've prioritised Geo, but I've not committed to it, so I therefore cannot give you any idea of dates", then that's not helpful to me. I still need to deliver my Geo capabilities, but all I know is that the team I'm dependent on may or may not do it, at some point in the future, and even though they have the best information about when that might be - because they know their priorities, workload and team size, better than I do - they're not willing to tell me what it is.

So, I need to work around them to get something done, and build it myself, even though there's a possibility that they'll deliver it in the timeframe I need. I have no other choice because they won't help me put a plan together. Sure, I've now avoided being affected by those "things that popup" but only because I've avoided having any dependency on the team that ought to be doing the work.

Other teams are making plans. Launching a product takes time. Meeting compliance deadlines takes time. Reskilling a workforce takes time. Getting contracts signed takes time. They are incorporating your roadmap into their plans, and if the roadmap you give is "I'm not willing to give you any predictions past the end of this month" then that's the roadap that they're basing their plans off. It absolves you of any responsibility because you never committed to anything, but the organisation as a whole suffers because everyone else is having to spend more time and money to work around you.

Very few organisations are or should be exclusively doing "innovative new things". Upgrades of old tech, compliance with new regulations, automating out dated processes. Those are all needed and rarely need innovative new things.

> it’s top of our list, we estimate starting on it after x”. Neither of these need a roadmap.

Because you've decided that "roadmap" is term that doesn't apply to "starting on it after x".

"We haven't started on this, but we will plan to do it next" is a roadmap!

"We like the idea, but the team are all busy on things that we expect to take up all their time for the next 6 months" is also a roadmap

As I said in my parent comment:

> You need _some_ form of roadmap to make this stuff work. The argument is about size (volume and duration) and flexibility.

It is unlikely that any organisation can/should do a 3 year roadmap. But a lot of teams already have a 6 month roadmap because they're already committed to that work.

Yet, the extreme alternative of being entirely unable/unwilling to answer the question: "I need this, when are you able provide it?" also has huge repercusions.

If your organisation is aiming to be more than a bunch of independent units that happen to share a balance sheet, you need co-ordination and sometimes that requires a roadmap.

If the internal "Database as a service" product team doesn't offer any sort of Geo capability, and I need it then I have to solve that problem. If that team cannot provide a roadmap, then I have to build a work around within my product team. This costs money, and that affects the P&L of the organisation. The organisation's goals are best met by having this capability built in the right place, with respect to upfront cost, ongoing cost and time to market.

You need _some_ form of roadmap to make this stuff work. The argument is about size (volume and duration) and flexibility. But those aren't absolutes, and we can argue forever about "how big is too big?" (but let's not). And so we end up with articles that talk in vagaries like "big change programs with detailed roadmaps" which doesn't mean much.

> This is a sweeping statement.

It also can quickly degrade to being horribly untrue. A product team justifies its headcount and activity decisions in a silo.

The product owner justifies a budget that translates roughly into team size and then sets to work on whatever satifies the objectives they've been given.

But a recurring truth of large organisations is that silos evolve to justify their own existence and size. You keep having $N people costing $X working on product $T because the product owner justified it to someone, not because it delivers the high benefits realization across the organisation.

The article's "New Silos" section just sweeps this to the side with "but it's better than the old silos". And it can be, but isn't definitively so. Any autonomous unit runs these risks, and unless the unit has its own P&L (with a real source of income, not just money taken from other people) preventing it from becoming bloated and serving its own desires (over the objectives of the organisation) takes hard work and requires proper oversight.

The code below takes ~15 seconds on 1 year old MacBook running Java 1.8.0_111-b14 and uses no 3rd party libraries:

        PBEKeySpec spec = new PBEKeySpec(password.toCharArray(), salt, 10_000_000, 256);
        SecretKeyFactory skf = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");     
        byte[] hash = skf.generateSecret(spec).getEncoded();

Is there a reason you would expect to be aware of them? Is this a field that you work in?

Your experience doesn't align with those of us who work in the application security and identity management space, yet you seem to be speaking so confidently about it.

As business have become more willing to move core services to cloud platforms, they've demanded that those platforms provide a single sign on solution that integrates with their corporate directory.

So, the popularity of SAML has certainly risen with the popularity of cloud / SaaS, but it's perfectly normal for a technology to become more popular with time (until it eventually goes into decline), and that increase in popularity means that it becomes more widely known, and some people who have never had to deal with it before, now come into contact with it.

I've been involved in SAML implementations at fairly conservative technology organisations (banks, pharma) for more than 6 years (and for most of that time it wasn't my core role). It's old tech, that's in wide usage, it just isn't something that most people need to deal with because it's boring identity management infrastructure that most application developers don't get involved in.

1. I guess "relatively new" is a vague term, but SAML v2.0 (the current version) was standardised in March 2005 - it's now 12.5 years old, I don't call that new.

2. SAML is very widely used in certain segments. Every SSO product supports SAML, including cloud vendors like Azure, Google and now AWS, and also specialist vendors like Okta and OneLogin. Within the dreaded "enterprise" space, SAML is absolutely the #1 SSO technology in play.

3. The golden SAML attack is a load of crap. It basically says "If you can get the private keys of an identity provider, then you can impersonate that identity provider". Yes, SAML relies on the confidentiality of the signing keys. That "attack" is the equivalent of saying Linux security is broken because if you have the root password you can modify any file.

Our scripting language "Painless" is faster and more secure than we could achieve with groovy, so in Elasticsearch 5.0 we made Painless the default and deprecated groovy.

In 6.0, groovy is gone.

We didn't do it to be minimalist, but we couldn't in good conscience continue to ship an insecure scripting language when we had an alternative.

Disclosure: I work at Elastic on security.

But I also know that I would be risking various legal and social consequences. A conviction for possession of drugs would affect my employment options, it would affect my travel options (visa forms often ask about such convictions), it may cause issues in the future if I ever got into a custody battle for my kids.

Given all of that, I have no plans to walk down the street and buy some weed from my friends' kids.

But I do have a collection of cigars in my house which I enjoy on occasion.

If it were possible to buy marijuana in the same way I can buy cigars, with the same legality, for a comparable price, then I might do so.

Now, I don't really see why society should care if I were to substitute some of my tobacco consumption with marijuana consumption, but there's a reasonable probability that this would be one of the outcomes if marijuana were totally legalised.

1. Somewhere in FB's patent portfolio is a patent that is broad and vague enough to cover some part of React, so the patent grant/revoke clause has meaning and value. Changing the license would mean that they were giving up something that they value, and they don't want to do that. That might not be true for RocksDB, in which changing the license is relatively low cost.

2. React is more widely used and more easy to detect (public facing websites) so the patent clause offers protection against a wider range of potential threats. Lots of sites use React, or react-like libraries.

Since the purpose of the patent clause is as a protection againt offensive patent suits, they seem to think (probably with good reason) that React is a worthwhile shield that they don't want to give up. For RocksDB they feel that balance is different.

The majority view seems to be that there are none.

But Facebook has a very large patent portfolio, so if they wanted to sue/counter-sue you, they could probably find something that was close enough to lock you up in litigation for a long time.