Homework Time
When I first got a copy of Nuance's Dragon dictation software, I really wanted to be able to define a single command to set up my computer to be ready to work. Today, I have finally achieved it! Telling my computer that it is "homework time" will open a terminal, a chrome webpage with Launch Academy's curriculum, and my Word document of notes - and it will assign them to portions of my screen using Divvy commands.
My current setup is an Automator Workflow triggered by a Dragon command, where the workflow is not only opening files but also using Apple script to trigger keywords. Is it efficient? Not a bit. Is it cool? Absolutely!
This week I also got the opportunity to attend a Q&A panel of Rubyist Employers, which was really informative. I met a few people in the field, and feel a little more confident about the job search post-bootcamp. The most interesting question that was asked was how the employers were structuring their interview process to be as fair and equal as possible. I hadn't thought about the situation from the employer's point of view - of course they want you to be as calm and relaxed as possible, because they want to know how you will behave every day on the job, not just how you behave in stressful interview situations.
One employer mentioned that they not only have a set of standard interview questions, but that they have also written lists of "good" and "bad" answers! It makes perfect sense if you're trying to remove bias from the process, but I love the programming-mindset-approach. It's like testing - you want to believe that a user will only go through the "happy" path of your application, but we all know that testing the "sad" path is extremely, if not more, important.
All of the employers mentioned that testing is an important skill that not enough applicants have applied themselves towards, and that they hate going to an applicant's github page, seeing a spec folder, and then discovering that it's empty! I can see a lot of test-writing in my immediate post-bootcamp life.
My current setup is an Automator Workflow triggered by a Dragon command, where the workflow is not only opening files but also using Apple script to trigger keywords. Is it efficient? Not a bit. Is it cool? Absolutely!
This week I also got the opportunity to attend a Q&A panel of Rubyist Employers, which was really informative. I met a few people in the field, and feel a little more confident about the job search post-bootcamp. The most interesting question that was asked was how the employers were structuring their interview process to be as fair and equal as possible. I hadn't thought about the situation from the employer's point of view - of course they want you to be as calm and relaxed as possible, because they want to know how you will behave every day on the job, not just how you behave in stressful interview situations.
One employer mentioned that they not only have a set of standard interview questions, but that they have also written lists of "good" and "bad" answers! It makes perfect sense if you're trying to remove bias from the process, but I love the programming-mindset-approach. It's like testing - you want to believe that a user will only go through the "happy" path of your application, but we all know that testing the "sad" path is extremely, if not more, important.
All of the employers mentioned that testing is an important skill that not enough applicants have applied themselves towards, and that they hate going to an applicant's github page, seeing a spec folder, and then discovering that it's empty! I can see a lot of test-writing in my immediate post-bootcamp life.
Comments
Post a Comment
Thank you for reading my blog! I look forward to hearing from you.