I am the "grand OP", the guy who was called out by the post. Statistically, only 20-30% of the candidates are nervous and about half of those end up passing. So we see no bias due to nervousness. On the other hand, the people that do not pass, in large part not nervous fail for different reasons:
- some are completely and utterly incompetent (they can't write a line of code at all)
- some write some code but it's just bad quality or they are incredibly slow
- some lack basic notions we require (e.g. don't know what a byte is)
- some blatantly cheat with ChatGPT or other tools
- some rage quit ("how dare you ask me to code")
- some fall into deep rabbit holes, overthink everything and make a mess
On the other hand the people that pass:
- all of them solve this in half the time we give
- even if they are nervous
In other words there's a chasm between the hires and no hires. Assuming that this interview only measures nervousness is a completely wrong notion.
BTW if you are interested in helping us transitioning the world from fossil to renewables, we are hiring: https://jobs.intellisync.it/
It's not only the sound, it's the sound, the bounce, the response to different strengths, the smell, the color. Humans are multimodal, machines are not, yet.
The moment we have a Michelin star level robot cook, then we can start thinking about automating this kind of stuff. For now, we have better results with humans!
Italians have absolutely zero problems replacing manual processes with technology. Creating each wheel is more science than art, everything is done in highly sterilized environments with exact temperature control, as an example.
As a person who's worked with the author (a great guy!) and with the F# community on a very large F# project: don't bother with F#, professionally speaking.
F# has many theoretical qualities, which make it fun if you like these things, but it also has some fundamental flaws, which is why it's not getting a wide professional adoption.
- the build system was a mess last I checked (slow, peculiar)
- syntax is not c-like or python-like (a big deal for a lot of people)
- you can't hire developers who know it (and certainly the few are not cheap)
- the community is a bit weird/obsessed/evangelizing (a turn off in a professional environment)
- it's clearly a second class citizen in the .net world (when stuff breaks, good luck getting support)
On the other hand
- it has discriminated unions
- units
- etc.
but do you need this stuff (not want: need)? most people don't.
The build system is exactly the same as C#, MSBuild with its .NET SDK, and syntax and community are entirely subjective; F# has the least weirdo community I've personally seen for an FP language. Weak arguments to say the least.
I'll give you the chicken-and-egg hiring problem and it being second-class to the .NET team, though; I'd add poor IDE support by modern standards, only Rider feels right. I love F# but I've moved on for these reasons.
I don't think this means what they think it means: a _lot_ of job postings get filled before they get counted. Think about it, there have been a lot of layoffs. Many of these people have friends that can refer them to jobs before they are posted.
A better graph would be of the number of people who self-report as being employed as software developer. I doubt that would show the same decline--there have not been many stories of people abandoning the profession because they could not find employment...
1. VSCode uses SSH (with its security profile) and the user can't do anything more with VSCode that they can already do with SSH. If the comparison is between a system without SSH and a system with VSCode and SSH--sure--I understand the concern, but it's an issue with enabling SSH and not VSCode.
2. VSCode can change files and persist? Well, it's a local editor, so yeah, it can change files and persist, that's literally its purpose. If that's an issue, disable editing permissions for the user.
Just a hunch that this could be a mistake of an overzealous community mod that thought that the nick Luigi Mangione was a troll... and that Evan Carroll is the best troll on the Stack Exchange network and he pushed the situation as he does and simply had the opposite effect than he thought he would ("Evan Carroll is flamebaiting again? There's no real problem, give him one year suspension" instead of "Oi, did someone make a mistake here here?")
Of course, I can be totally wrong but I've seen these things happen (I've been both a mod and a core dev at Stack closely working with the community team 8 years ago)
You can't be the best troll, if you never troll: I never troll, ever. But other than that. Luigi's acct wasn't renamed by a community mod, from Zoe and as quoted in the article
> I can confirm SE, Inc. were the ones to clear his name. A reason was not specified anywhere obvious. Mods have been given explicit instructions not to touch that profile. While this particular incident may be limited to SO, the implications of this affect the entire network
In reality most candidate are just bad at estimating their own skills (in both directions) and of course they know almost nothing about the match between the skills and the position.
- the candidate has a range of salary they expect or need
- the company has a range of salaries that they can pay
If these don't overlap there's no point going forward unless the range of the company is higher.
If these do overlap, it's worthwhile proceeding. Then it's a matter of skill. If you apply and ask for the top range in my salary band, and you are truly exceptional, I'll do my best to match it. But the ask needs to be commensurate to the skills you demonstrate in the interviews. The higher the ask, the stricter the criteria to match.
If you get to the end of the process without disclosing the salary, and you pass all interviews, I'll offer you for what I think you are worth. If you have an ask and did not disclose it, you might have just wasted everybody's time.
Believe it or not, negotiating a salary higher than your worth is a terrible idea. It might sound good, but it sets you up for failure.
Nothing is more insulting to someone than knowing in advance that their expectations are far beyond your own, putting them through hours of interviews, then offering half the salary they asked for plus funny money equity.
I try to be as up front as possible with my expectations, but I've also got the seniority / experience to match what I'm asking for. Yet, people still try to low ball me as if I'm making up numbers.
I made the mistake once of taking a job after they low balled me, then met my asking salary after I flatly said no.
If you ask for a specific number or a range, and they offer you below that range, just walk away. Even if they come back with what you wanted, they'll resent your salary and have inflated expectations above reality. They've already demonstrated they didn't take you seriously. Just walk away.
Even if they come back with what you wanted, they'll resent your salary and have inflated expectations above reality
that is something i worry about when i see a high offer. in part it's imposter syndrome, but also a lot of job descriptions are like we want the best, and you are super fast and an excellent this and perfect that, able to work in a high pressure environment, etc.
these claims are so meaningless. they don't tell me anything about what it is really like to work there.
who really wants to work in a high pressure environment with the expectation to be a rock star developer?
This really depends on the company. If they have interviewed you and made an offer, then it is only a question of whether you think they got to know you.
Personally, I like small companies / startups with a bit more pressure. People focus more on getting things done than playing politics and bike shedding. I can absolutely understand it is not for everyone though.
With regards to what you quoted, I was referring to the scenario where their initial offer was below your expectations, you said no, and they made a second offer that met your expectations. In this case, you're right, there is no way that you and the company have the same view of the monetary worth of your contributions. The well has been poisoned from the start.
i have worked in startups, and i don't mind the pressure that comes from the high risk a startup is taking, but when i see a 500+ employee company with a job ad that says "you strive in a high pressure environment", then i wonder just what kind of pressure they are talking about.
I honestly do not understand ActiveRecord and ORMs in general. There is the obvious advantage of mapping, for which one merely needs microORMs. Even by reading this article one realizes that for anything complex, it is much simpler to directly write SQL queries rather than use byzantine techniques whose only raison d'etre is to coerce the ORM into writing those SQL queries. I mean -- why not write SQL directly? :-)
There's the not-so-common case of needing database independence as well, but at that point DB perf becomes a really hard problem to solve generally...
If you're encountering these problems at scale where scale is up to the reader, I can promise you that you're already writing SQL. You might have already started from the beginning by writing direct SQL, because that's something that rails also allows you to do against a model. Apart from juniors, I don't think I've ever met anyone who actually said that they wanted to avoid writing SQL in all cases. The reality is that it's far more useful and efficient to burn cpu time than dev time, and ORMs general tend towards the latter than the former in the favor of generally being a fair bit more legible (depending on the writer).
As a semi-counter-point, learning some data mapper libraries where you learn a DSL that seems better-structured than SQL definitely helped me understand SQL better.
SQL is ultimately a bit dysfunctional and takes a lot of getting used to. Not arguing it's worth learning but since most of my career I was not truly exposed to it, I preferred the bespoke DSL.
I'll agree using ORMs is indeed going to ridiculous lengths to avoid learning even a smidgen of SQL but there's a nice middle ground.
Say you have a SQL database on one side, and a Python/Ruby/Java/Golang webserver on the other. If you wrote raw SQL, you'd have to also write the ORM (the object-relational mapper) yourself as well to map database results into objects or whatever data structure your webserver expects.
In the sense that in Java (almost) everything is an object, a jOOQ query must of course return an object (such as a Record2<String, String>), but unlike Hibernate or AR, jOOQ doesn't enforce a 1:1 mapping between domain objects and tables, especially if you turn off POJO generation - at my last company, we had some custom mapping from a table to several subclasses of a sealed class depending on certain fields in the table - and you can even split a single class into two tables etc.
> In the sense that in Java (almost) everything is an object,
no, this is misleading. There are different kinds of objects. if you use JDBC to run a query you get back something like a Row object (sorry I havent done JDBC since the 1990s) - the "Row" like object does not declaratively define the fields of the row, the fields and the data of each field are all data. however when you get back POJOs, as you say, these declaratively define the fields that are "mapped" to a column. if jOOQ does this, it's an ORM. ORM has nothing to do with writing SQL - that's called a "SQL builder". the ORM is about marshalling data from POJO-style objects to and from relational database rows.
There are different ways of using jOOQ, some of them being more like an ORM (but still more low-level than Hibernate) and others less so. You can use the API in such a way that it just returns a general tuple object holding the result from your query (called Record1<T>, Record2<T1, T2>, etc.). This is especially useful when fetching from multiple tables. You can also use codegen to auto-create POJOs and mapping code, but this is not required.
"Unlike ORM frameworks, MyBatis does not map Java objects to database tables but Java methods to SQL statements." https://en.wikipedia.org/wiki/MyBatis
"Jdbi is not an ORM. It is a convenience library to make Java database operations simpler and more pleasant to program than raw JDBC." https://jdbi.org/
"While jOOQ is not a full fledged ORM (as in an object graph persistence framework), there is still some convenience available to avoid hand-writing boring SQL for every day CRUD. That's the UpdatableRecord API [which is only one part of it and you don't have to use it]" https://blog.jooq.org/how-to-use-jooqs-updatablerecord-for-c...
ORMs do not require SQL builders. Textual, hand constructed SQL to rows based on tables mapped to objects and you get objects back. "Why don't people learn SQL?" as a retort for ORMs is incorrect.
This is about ActiveRecord, which tries very hard to convince you that a relational database works like objects in memory, especially when it comes to associations, saving etc. Hibernate is similar in that regard (although it at least enforces repositories, but you can still have surprises when it comes to when it loads associated tables). Both allow you to drop down to SQL but then you lose syntax checking / type safety and the conveniences of the library.
With something like jOOQ, the query language is basically SQL, just made type-safe. You write a query that maps to an SQL query 1:1 and then you map the results to whatever you need. No implicit saving, auto-loading of associations in the background etc.
So it's not about "people should use the SQL syntax instead of query builders", it's "people should write relational queries explicitly instead of relying on the framework to save and load stuff from the database when it deems it necessary". Your domain objects do not need to know that they're persisted and they don't need to carry a DB connection around at all times (looking at you, ActiveRecord).
Speed to market. One person or a very small team can build a feature-rich app in Rails (or equivalent framework) faster than any other approach.
Plenty of companies end up building the wrong product altogether and need to pivot when they realize customers don't care about feature X and need feature Y instead. In cases like these you hope you get the right product out there and survive long enough to regret building with the fast framework instead of the finely tuned ultra performant version.
It’s really handy to have a composable API for building SQL queries where different elements are contributed by different parts of the code. From example, having your authorisation code apply restrictions to queries through where clauses, joins, etc. to ensure a user only sees the records they are allowed to see.
I currently spend a large proportion of my time working in a Java code base that uses JDBC directly. There are many places where the complexity of the work to be done means code is being used to assemble the final SQL query based on conditionals and then the same conditional structure must be used to bind parameter values. Yes, in some places there are entire SQL statements as String literals, but that only really works for simple scenarios. There are also many bits of code that wrap up common query patterns, reimplementing some of what an ORM might bring.
I recently implemented soft deletion for one of the main entities in the system, and having to review every query for the table involved to see whether it needed the deleted_at field adding to the where clause took a significant amount of time. I think better architecture supported by a more structured query builder would have made this much easier. For me that’s the main benefit of an ORM.
A well-designed ORM can help you with performance, for example, by reducing the amount of effort to do things like fetch related records in a single query. The really good ones also handle migrations. And finally, all of the popular ones I'm aware of allow developers to use them just for mapping results to objects. I would say that in general the further an ORM strays from SQL concepts the more troublesome it is likely to be. If the query syntax looks like Mongo, then you probably won't have a good time when doing more advanced things.
Yeah … for want of easy serializing to classes and what not I hate the ORM approach. The database is already a black box. Stats might be out of whack. The indexes might be bad. Etc etc. now add magic that the ORM does.
- some are completely and utterly incompetent (they can't write a line of code at all)
- some write some code but it's just bad quality or they are incredibly slow
- some lack basic notions we require (e.g. don't know what a byte is)
- some blatantly cheat with ChatGPT or other tools
- some rage quit ("how dare you ask me to code")
- some fall into deep rabbit holes, overthink everything and make a mess
On the other hand the people that pass:
- all of them solve this in half the time we give
- even if they are nervous
In other words there's a chasm between the hires and no hires. Assuming that this interview only measures nervousness is a completely wrong notion.
BTW if you are interested in helping us transitioning the world from fossil to renewables, we are hiring: https://jobs.intellisync.it/