@jonandersense Honestly, I prefer doing a 1 day onsite interview. The equation is different here. Here, the company is investing as much time in interviewing me as I am putting in them. It sounds fair.
But doing half a day coding exercise even before any technical interviewer in the company is ready to talk to me has a very imbalanced investment of time from both sides. I invest 4 hours in the company when the company invests none.
In that case, we agree. I too believe that a 1 hour coding interview is reasonable although I am not too sure if it is ethical to do so without paying. But if it is a 4 hour coding interview without pay, I am certain that it is unethical.
Since you asked for alternatives, here are some suggestions I have:
- If you want to do a 4 hour coding round even before a phone interview, at least pay for your candidate's time and effort.
- Otherwise, restrict your coding round to 1 hour. I think this strikes the right balance between lack of pay and my time spent.
A 4 hour coding assignment is half a day of work. I don't care if it is a toy project and if there is no business value in the work. But a 4 hour coding assignment is still half a day.
I may have to take a leave from my current work, take half a day off off my current contract or spend a significant part of my weekend on this problem, instead of with my family. I certainly expect to be paid for it.
The number of commands you show may not be unreasonable. But after spending many years in the industry, I think it is far easier for me to learn C++ with all its different types of pointers than it is to learn what Git is trying to tell me when I have screwed up something.
Either Git has a complex user interface like I claim or I am beginning to grow old.
To be fair to the people whose merges failed, I believe this is a shortcoming of git (the tool) and not the people using it.
It is fair to expect a developer to invest sometime in learning their tools well but git is a different beast. I know it solves a very complex problem but the fact that it exposes a complex interface to the user to do so seems like a shortcoming of the tool to me.
Heck, we even have a comic for it that shows how sometimes just saving my work, deleting my clone, re-cloning the repo and applying the changes in my work is easier than understanding the Git error messages: https://xkcd.com/1597/.
The tooltip in the comic is also sound advice: If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything.
> I'd much rather have a well rounded individual who isn't moonlighting on other things but rather can bring his clear focused mind to the office.
I don't understand how you equate doing side code projects to not bringing clear focused mind to the office.
Would you also much rather bring a well rounded individual who does not take art classes after work? Do you think taking arts classes after work would affect one's ability to focus in the office?
Then why do you make similar assumptions about doing side code projects? For many of us, doing side code project is like taking art classes. It is art for us and it helps us learn new things about the art of software development that is not always easy to learn in the constraints of real world software business. Most importantly, it is a relaxing and enjoyable experience. It refreshes our soul and combined with a good night's sleep, it helps us to better focus next day at work, not the other way around.
Are you saying that you would much rather not hire people like us who care about the art of software development because from your high horse, we don't look like "well rounded" individuals? If you hold this kind of irrational conservative beliefs, I'd much rather not work for you.
Saka Key seems to be using different keybindings than VimFx, Vimium, Vimperator, etc. For example, Saka Key uses `n` to open a new tab[1] whereas others use `t` to open a new tab. I am more used to the latter. So I decided to ignore this and try Vimium instead.
Vimium is good but one thing about Vimium annoys and I don't know a good workaround for it. If I create a new tab, the focus goes to address bar and then there is no convenient way to escape back to normal mode. I know this is a restriction due to the new webextensions. Anyone got any ideas to overcome this limitation?
The fact that you were not aware how Vim is different than other editor (editing language vs. keyboard shortcuts) shows that you use your current editor as a macro for keyboard shortcuts rather than something you can talk to with little verbs and nouns and combine them into complex editing instructions with ease.
There is no way you can match my speed and productivity of editing and refactoring code with that kind of approach to editors.
"The point of this exercise is to benchmark your writing skills. Write an approximately 500 word article about something you're passionate about that's technology related."
The holier-than-thou approach taken here is sickening. Why does this company expect a prospective employee to do all this without even a guaranteed date for an interview?
They have invented a deplorable interview screening procedure where the company has to invest zero time on the candidate but the candidate has to dedicate a few hours to prove that you can read and write before they are willing to engage in a conversation with you. This inequality is disgraceful.
You cannot remap Caps Lock key with Microsoft Keyboard Layout Creator. If it were really that straightforward, then Vim users would not be forced to rely on registry hacks or tools like Uncap or AutoHotKey to map Caps Lock to Escape [0].
If you dislike editing Windows registry like me, you need a separate program to be running.
Does anyone know anyway to look at the linear commit history alone (not GitHub) and tell where a pull request was merged and who merged it?