This is my preferred option also but I love reading the comments when these sorts of posts appear as it seems that interviewing is still something that causes loads of debate and no matter whether the op is whiteboard, tricky algorithm or <other> focussed, there’s still a hot debate. Interviewing just seems broken
It must surely boil down to the profession aspect. Doctors and lawyers do a period of internship after and during the degree that perhaps mitigates the uncertainty around hiring. I doubt that doctors are asked to bring in a cadaver to operate on during an interview for a new position, or lawyers are asked to jump into court unprepared and defend someone as part of the hiring practice.
It sometimes seems that programming jobs need to be a calling. Ie: you spend 50 hours a week at job doing the thing but then are also asked to have a portfolio on the side that you presumably do in your spare time.
It could just be an American thing, though. Perhaps hiring is seen as very risky because sv salaries are so out of proportion to the standard across the rest of the working environment, in addition to there being very little quality control regarding professionalism in the industry that makes technical hiring such a minefield.
It's not. You'll find plenty of anecdotes outside the US. Even just outside SV is enough to put things into question, as salaries outside SV are way lower.
>Doctors and lawyers do a period of internship after and during the degree that perhaps mitigates the uncertainty around hiring.
Two problems with this.
For one, this is changing rapidly. Any institute of higher education is becoming a worker factory focusing on what the industry wants in candidates rapidly. Despite this, interviewers continue to complain about the most minor things which in reality are very easy to grasp for people with a degree and some projects.
For two, this problem still persists after having some years of experience under your belt. If an internship mitigates the need for other professions to go through this, surely having verifiable experience should do the same. But it doesn't, and it takes away a lot of time from people to build their own portfolio to get through interviews with too.
>It must surely boil down to the profession aspect.
I don't believe so. Hiring is plagued with perfectionism and idealism, looking for the perfect candidates and failing candidates over the most minor things. You could actually be the best candidate in the world, and you'll fail because you said something or did something in a way the interviewer preemptively labels as "unviable".
The problem is actually as you point out: hiring managers are pushing risks onto individuals in the name of "calling", and loads of developers are doing nothing to push back on it. Or worse, they are encouraging it. See also why the average junior requirements includes an entire IT department's worth of skills.
I found that it depends on where your interest lies.
If you just want to learn practical SQL then I have historically found the Celko books (https://en.wikipedia.org/wiki/Joe_Celko) as well as, more recently, the No Starch Press books (https://nostarch.com/practical-sql-2nd-edition) very well written.
Everyone learns differently however. I have a colleague who really enjoyed the O’Reilly books specific to SQL from a data analytics perspective. (Apologies, no link for that)
You might frequently find the No Starch and O’Reilly books on Humble Bundle, (https://www.humblebundle.com/books?hmb_source=navbar) if that is available in your location.There’s often loads of overlap between bundles. I’m sure I’ve bought the python book about 5 times so far but I don’t mind as it’s great value.
If you want to learn about database theory, however, as well as the practicalities of SQL, then I found that most of the resources I used when I did this at uni were online. The book we used was the Connolly/Begg book (https://www.pearson.com/us/higher-education/program/Connolly...)
I don’t think this effectively answered the “why” of your question, however. My guess is that SQL is a very well established domain language and when it comes to data normalised across many tuples it’s the standard for manipulation.
I don’t think that dataset size is the primary reason to manipulate data via SQL; I think that the moment your programme starts to need more than a single flat file data source, you naturally start to think about normalisation, indexes etc for performance and sanity.
If I may, however: I am coming at this from the other way in that I am far more often manipulating CSV and excel data and would like some good resources in how to quickly load that in to a dataframe in pandas or similar vs using SQL. (If I’m responding to a thread hijack I may as well go all in and totally derail it)
The SQLite shell supports importing and writing CSVs pretty easily - here are some snippets I reach for often enough to copy to a blog post:https://www.bbkane.com/blog/sqlite3-snippets/
So uhh, when are you gunna use a dataframe and when will you stick to SQL?
My understanding is that SQL can sorta do a very powerful (and standardized/fast) subset of what a dataframe can
I’ve used PostGIS with a Flask (and some js) front end when I was working on my MSc. (Mapping deprivation and services by postcode)
Worked amazingly well and was relatively easy to get used to once I read the O’Reilly PostGIS book to get used to the function calls. As with any data project; munging the data into a usable format was the biggest hassle.
Edit: used google maps for the display before they changed their licence. Haven’t updated to OSM yet...
Same. I use Flask because it's one of the lightest frameworks I could find. GeoJSON can be generated on the fly by PostGIS with very good performance. So Flask is just used as middleware to submit the query from URL params to PostgreSQL.
For the front-end I usually use Leaflet with Mapbox (raster) tiles. I should switch to vector tiles but "@2x" raster tiles look good enough on HiDPI/Retina displays.
I'm also an heavy QGIS user. I've managed to convince IT to put it in our internal Software Center so users can install it in one click without needing to be admin. It's becoming quite successful internally ;-). Take this Esri!
However we still pay hundreds of k€ to Esri and nothing to QGIS. I've personnally donated a few euros but it's a really small amount compared to what we pay to Esri.
