Install Doom Emacs and the linked config, and use Emacs with VSCode-esque keybindings and look-and-feel. Good for Emacs newbies with prior VSCode experience.
We don't charge anyone for doing the projects and all the code that a person does is owned by themselves (we dont even host your code or know where it is). Anyone that works on Zyring can do whatever they want with their code.
There is not one single other engineering profession I'm aware of that thinks a "portfolio" consisting of past employment is insufficient, or that has academic trivia questions figure as largely in their interview process.
To me a request for portfolio contents beyond the contents of a resume is an indicator that the would-be employer is interested in people who are easily exploited or cajoled into working lots of unpaid overtime, or else that they don't actually trust the candidate's resume; both of these are negative indicators. A heavy focus on DS/algorithms for engineering positions is an indicator that the employer either doesn't understand the difference between academics/theory and engineering or, worse, thinks the latter is trivial, irrelevant, or otherwise beneath CS; both also negative indicators.
what you are saying is relatively true for developers with some experience, especially engineers. This is not true for people coming out of online learning programs who know the basics of coding but haven't built anything significant. For these people, the resume is empty so building a portfolio of significant projects is a way to become a developer. It is as much self-serving as it is serving the needs of employers.
That's true, and it is a case that seems to be unique to the software field as far as engineering is concerned. I'm also unaware of any other engineering profession in which such shallow education and experience would be considered acceptable in any case. Usually a four-year degree from an accredited engineering school is a minimum requirement for even entry-level work. In these cases references and some casual "technical" discussions (but nothing like the pedantic Algo/DS grilling in a software interview) in the interviews will determine suitability, and the individual will effectively be considered a trainee for a time. That is also absent in the software industry, generally.
> I'm guessing you are someone who does not enjoy programming? Did your parents pressure you to take it up to have a well paying job?
I do like programming, and I can at least empathize with the parent's skepticism. I do recall the lessons that my other freelance colleagues have told me about 'work-for-free' schemes in different forms. I don't think that's what is happening here but I can understand why some might feel that way.
The biggest advantage I see is HTML imports [1] finally providing a common bundling mechanism for HTML/CSS/JS. Custom elements can also finally get devs out of <div> hell.
Fast coders know their languages, frameworks and tools like the back of their hand. They eat docs for breakfast, have a knack for memorizing it, and an even stronger knack for making sense of it.
Sounds like a job add at the Startup From Hell.
Fast is a subjective term. How would you quantify? LOC/hour ? Words per minute?
There is no such thing as a "fast coder". You could differentiate from "mostly beginner" and "somewhat experienced" but that's about it, and even that is subjective.
I find "coder" a demeaning term and prefer programmer or developer.
Do you know a programmer that recommends himself as a "fast coder" ?
(Other than a job starved dev, in a low income country, to a low budget - low quality dev shop ?)
As DHH says, the main factor of velocity is feature negotiation: shaving off the 20% of stuff that takes 80% of time.
Use something like Bundler, Maven, Pip, npm, sbt. For example bundler has the `$> bundler outdated` command that shows dependencies that have new versions.
