Springest wants to become the largest source for learning in the world. From books and e-learning courses to onsite trainings, we help our users discover, compare, and book everything they need to reach their personal and professional learning goals.
We have a strong product focus in which everything revolves around the users of our Dutch, German, UK, and US sites. Next to that, more and more organisations are using our SaaS tools to stimulate and manage learning for their employees.
Working at Springest
We are looking for senior Ruby developers to join our growing engineering team. We don’t have managers at Springest, but processes, and we feel that individuals taking responsibility is very important. At Springest, you will work in close collaboration with product owners, marketing, and sales colleagues. You are also a member of our development team where we discuss architecture, infrastructure, and keep a close watch on security and performance.
Our main application runs on Ruby on Rails backed by Postgres, Redis and Memcached. Next to that we rely on Elasticsearch to power our search which is a big part of our product. We also have some smaller Go and Elixir projects in production.
We are hosted on AWS and make heavy use of their offerings like RDS, CloudWatch, Elastic Beanstalk and EC2 Container Service.
Next to our main application we build internal tools whenever necessary to help ourselves and our growing Learning Advisor team. It is extremely rewarding to see small development projects make a big impact for other Springeteers, which in turn can result in more of our visitors being helped of course!
We do a regular internal hackday every month where we drop everything and work on something completely different, which we feel is super valuable for coming up with new ideas. We might give a new programming language a shot, try out an idea someone’s been toying with for a while or hack on some actual hardware (that’s our temperature sensor above in its beginning stages!).
A lot of hackday ideas actually became super important for our company, its a great chance to experiment with something that could grow out to become a key factor of our business.
Check our recap of the most recent hackday to read more about why we organise them.
Your New Colleagues
At Springest you will work with around thirty colleagues (that’s not all of us and no we’re not always in full cowboy gear, this was our Western themed SpringFest!) who all are very skilled at what they do and all of them have a healthy dose of nerd skills that we really value. Our Product Owners also regularly ship code!
Springeteers are a happy bunch and we often get together outside work to enjoy free time as well. Our office is a cosy place where anything goes and where we all take good care of together. If you’re not good at ping-pong yet, you have a good chance of becoming good here as well! 🏓.
We are all active organisers and members of Meetups and other forms of knowledge exchange (learning is our hobby!) and we participate quite actively in the Amsterdam startup ecosystem. In addition to that we get a lot of attention for Springest being the poster boy of how Holacracy and GTD can work for an organisation, which in turn is due to our organisational structure without managers and other unnecessary overhead.
What we expect from you
- You work well in a team, and want to make the team greater than a sum of its parts.
- Engagement in what it is that you are building and who you are building it for. We want you to feel involved and come up with ways to make Springest better.
- The drive to improve yourself and our organisation and deliver high quality work.
- You have a broad interest and deep knowledge, certainly not just in/about Ruby. We are all about learning and sharing knowledge.
What You Get From Us
Apart from Springest being the coolest company you will ever work for, there are a few extras:
- We are very remote friendly.
- At least a € 1,000 education budget per year to spend on training, courses, and conferences.
- Stock options after 2 years.
- A cool workplace in the center of Amsterdam with height adjustable desks that you can sit and stand at, table tennis, a massage chair, and balcony with a barbecue.
- A Macbook from us or upgrades to your own.
- All software and hardware you need to do your job and have an optimal workflow.
Contact Mark Mulder (firstname.lastname@example.org) for questions and applications. Please include links to your Github and LinkedIn profiles.
Checkout these links to get to know more about us:Read more
An Inside Look at Our Awesome All-Company Hackathons
Hack Day has long been a tradition on the Springest team. We’ve built some amazing prototypes in ridiculously short timeframes — some of which have gone on to become real product features.
Uniquely, we also don’t limit Hack Day to the development team. From marketing to sales and customer support, everyone at Springest takes part in our monthly all-company hackathons.
Why we hack
We have a few core goals for each hack day:
- Innovate: Work on something not on our usual roadmap.
- Learn something: Try out a new coding language, service, or skill.
- Have fun: Whatever you do, it should inspire you.
All month long, Springeteers are encouraged to keep track of inefficiencies in their workflow and brainstorm possible solutions.
Is there a boring, repetitive task taking up way too much of your time? Let’s find a way to automate it. Is there a key metric that takes forever to compute? Let’s write a script to calculate it for you.
For coders and non-coders alike, there are plenty of awesome tech tools to hack your way to a more productive workday.
For high-tech solutions, developers are brought in for cross-team collaborations, which often produce the most interesting results. For example, our grumpy Smooth Operations team ended up with a Raspberry Pi hooked up to a temperature sensor, complete with on-demand Slack notifications.
Hack Day starts at 9:30am with an all-team meeting. We each present our ideas to the group, which often involves convincing other skilled team members to join in on a big idea. Afterwards, we’re all free to choose what we work on, and we turn on some music before settling into our projects.
5pm is demo time. While some still hunch over our computers making final tweaks, the rest of us crowd into the kitchen to see whatever working (or almost-working) prototypes made it out the door.
While we don’t have prizes or accolades for “winning” ideas, there is always plenty of beer and applause to go around.
And what exactly did we achieve this month? Here’s an inside look at this month’s Hack Day projects:
Revenue Wall of Fame
Hacker: Ewout Meijer, Director of Corporate Partnerships
Problem: We hit revenue records all the time, but we have no easy way to see whether a high number is our true ‘record’ without looking it up. That’s lame - we should know when to celebrate!
Hack: Display the “Revenue Record” output of our Google Sheets metrics on a giant screen, so everyone can see it and get stoked.
Gym Class Line Jumper
Hacker: Liz Hubertz, Software Developer
Problem: Gym classes are always full, and you have to be SO fast to register when a “you’re off the wait list!” email is sent. This decreases workday productivity, because you’re always looking out for that email.
Hack: Used Zapier to trigger a webhook when the email is received, then built a small Rails app to handle the automatic login and registration process. Classes are thus instantly booked upon receipt of the “you’re off the wait list!” email.
SSL Quality Slack Notification
Hacker: Tim Flapper, Software Developer
Problem: We currently have no way to easily and conveniently monitor our SSL setup. Wouldn’t it be awesome to get a notification right in Slack? Yes.
Learning Advisor Booking Scoreboard
Hackers: Midas and Merel, Learning Advisors (Customer Support)
Problem: An important part of measuring the success of our Learning Advisors is knowing how many bookings they achieve per week. This data therefore needs to be easy to find and visible for everyone.
Hack: By linking Slack with Google Docs with Zapier, they made an automated scoreboard that keeps track of how many bookings were done by Learning Advisors and how many were done by users themselves on our site. The scoreboard will be displayed on the TV screen in the Learning Advisor corner, so they can always see how they are performing that week.
New Springeteer Onboarding Program
Hackers: Debbie van Veen, Smooth Operations Lead and Anne Nynke Jansma, Learning Advisor
Problem: Our current onboarding process feels like it can be improved, but we don’t have any data to back up how or why!
Hack: Next to partially rewriting our onboarding help articles and making clearer tasks, they also created a survey for new Springeteers to track how often our tools are used and what people think of the program / what they miss.
Automated Inbound Lead Email Flow
Hacker: Sofie Angevaare, Marketing
Problem: We lose out on a lot of useful leads by not using smart enough filters on our inbound flow.
Hack: Brand new automated e-mail flow that identifies whether our users should be followed up on by our provider sales team, plus a Slack notification whenever a key user is identified.
Polish ALL the Things!
Hacker: Rik Matena, Product Owner
Problem: Rik has been working on an internal customer support tool called Scoutest for awhile, but there are always improvements to be made. As a technical guy in his own right, he also helped out non-tech folks with their hacks.
Hack: Awesome UX improvements and a working and beautiful display for Ewout’s Wall of Records hack.
Hacker: Dennis Paagman, Product Owner and Developer
Problem: We want to use data from our internal tool ASQ in external applications, which generates key metrics based on saved SQL. This allows us, for example, to automate filling in KPI metrics in our Google Sheets.
Hack: Built the API! Awesome!
Hacker: Dennis Paagman, Product Owner and Developer
Problem: It would be nice to visualise our corporate sales pipeline, but deals take a long time to go through - making it seem like not much is happening.
Hack: Pldealio deal pipeline timeline!
Learning Advisor Reviews
Hackers: Zoe van Dantzig and Maarten Butterman, Learning Advisors
Problem: Our product focuses on quality reviews, so why don’t we let our users review our customer support team?
Hack: Created Springest trainer accounts for each Learning Advisor. Customers can now rate our customer support team in the same way that they rate trainers on the Springest website.
Notifilter API & Slack Bot
Hacker: Mark Mulder, Software Developer
Problem: Mark built an awesome internal tool called Notifilter that would be super useful with an API, because that would allow us to grab statistics and re-use these numbers in Sheets, post them to Slack, etc.
Hack: Notifilter API and Slack Bot is now live!
I hope our examples give you some inspiration to try out your own all-company hackathon. While not all of our hacks will survive the test of time, Hack Days promote inter-team communication, collaboration, and learning. Plus, it’s a great way to ultimately boost employee happiness and productivity — not to mention an excuse to drink beer during work hours. ;-)Read more
Last week, I was invited to speak to an audience of international students at the 2016 International Talent Event Amsterdam (ITEA). The goal of this event is to help young people figure out how they want to start their careers, and my job was to give them an idea of why they might (or might not) want to pursue life at a tech startup.
I presented alongside Ruben Nieuwenhuis of StartupAmsterdam and Mariette Ruggenberg of Upstarter, both Dutch natives and veterans of the Amsterdam startup community. My story was a bit different, as I’m an American who before now had only worked in Silicon Valley. I’m also an engineer, which is a very different perspective from life as a startup founder.
As for my story, the first part of my career focused on huge enterprise organizations - we’re talking corporate behemoths like McAfee, Microsoft, Intel and VMware. The second was focused solely on early-stage startups - companies you’ve probably never heard of working out of a tiny co-working space in the Mission district of San Francisco.
So, what is my advice for students considering a startup?
Find out what founding or working for a startup really means
Myth 1: Funding comes first
Q: I have an idea. How do I get funding to build my business?
A: By building your business.
Unless you are well-known to investors or are a serial entrepreneur, you will need a prototype up and running and your founding team put together before you ask for funding. This is the time where you rent out your mother’s basement, survive on ramen noodles, and work your ass off for free until you have something that makes an investor think, “ok, these guys are at least worth a shot.”
Sure it’s hard work, but so is anything worth doing.
Myth 2: You don’t need to be technical
Myth 3: You must be a designer, coder, or growth hacker
A couple of law students asked this question during our panel: “I’m a lawyer, but startups don’t really hire lawyers. Should I learn to code?”
This struck me as an odd question, seeing as every startup I’ve ever come into contact with has in fact hired lawyers. They just haven’t hired full-time lawyers on staff. (Though I’m sure legal startups like fixed certainly do.)
If you’re not looking for a career switch, don’t feel like you need to change paths just to fit into the “startup box.” Broaden your view to the entire ecosystem that thrives in places like Silicon Valley to support the growth of small business.
Are you a lawyer? Check out firms that specialize in helping small businesses get off the ground. Are you a marketing professional? Plenty of agencies contract with tiny startups before they’ve grown large enough for an internal marketing team. And of course, if you’re a recent MBA, you can always try your hand at the venture capital game.
Myth 4: Startups are better than big companies (or vice-versa)
The awesome and irritating part about this is that it’s 100% up to you. To figure out which is “better,” you just need to figure out what you want from your next job.
Both startups and big companies come with pros and cons, and you’ll need to weigh those options against your current career goals. For example, big companies are known for offering generous salaries, growth opportunities, and senior mentorship - but also for prohibitive bureaucracy and skill stagnation. A startup, on the other hand, will give you the opportunity to take on new roles every day, and there’s no question that your work will make an impact. But with that usually comes a drop in salary, free time, and job stability.
TL;DR: Your career is what you make of it
Startups and large enterprise companies both have their place, and eventually one will morph into the other (hello Google and Facebook). So students, stop stressing! Building your career is a lifelong process, and you have time to pursue both worlds. In fact, I’d argue that the more experience you have in all sorts of career environments, the more valuable of an employee (and human being) you will be.Read more
I started using vim together with tmux a couple of months ago. After surviving my first week, I organized a workshop to share what I learned with the rest of the team and convince the resistors to switch. :)
This post will focus on tmux, but stay tuned for a follow-up post about vim!
First things first, so what’s tmux? Well, taken from their own documentation:
Tmux is a terminal multiplexer which lets you switch easily between several programs in one terminal, detach them and reattach them to a different terminal.
Which basically makes your terminal look like this:
Now you might be wondering, what’s the difference between tmux and what I have now?
For many people, the main reason to use tmux windows over tabbed terminals is that with regular terminals, if the window manager crashes, you’ll lose the terminals as well. However, this won’t happen with tmux, which keeps the terminals running in the background. You can re-attach a new terminal to them at any time. What I also like about it is that I can create sessions for each of my projects. This keeps them organized and makes it very easy to switch between them, so you can find projects exactly where you left them. ;)
Awesome! To start using tmux you need to install it first. If you are already using Homebrew to manage your packages, you can just run:
Below I will guide you through some changes in the configuration to make it behave in a more intuitive way. These changes need to be done in the
~/.tmux.conffile, so if you still don’t have that file, go and create it now:
Meeting the “prefix”
First of all let me introduce you to “prefix” because every time that you want to “speak” to tmux you will need to use it. Its default value is
Ctrl+b, but it can be changed to any keybinding that best fits your fingers. ;) In my case, I decided to bind it to
At this point it can also be quite useful to remap the Caps Lock key to Control. If you are using Mac you need to go to the section Modifier Keys under your Keyboard preferences and select Control for Caps Lock.
Finding a friend
While I was hunting for some inspiration before deciding to give tmux and vim a shot, I came across this talk by Mike Coutermarsh in which he shares some very good tips. This is one of them: copy the configuration file from a friend. He is referring to
vimrc, but it also counts for the
tmux.conffile. You can have a look at my configuration here, which is a modified version of Thoughtbot’s and Mike Coutermarsh’s.
Reloading the configuration
Whenever you find yourself making any changes in the configuration, don’t forget to reload it by running:
Which I have bound to
tmux objects overview
Before we move on with some other configuration tips, let’s talk briefly about some important concepts that will help you understand how tmux works.
The first concept to be aware of is sessions. A session refers to a named collection of one or more windows. Typically I will create one session for each of my projects and give it the name of the project.
Next comes windows. A window refers to a single screen within tmux, similar to tabs in terminal applications or browsers. Remember that at any given time, a client will be attached to a single window.
Last but not least, we find panes. A pane refers to a portion of a window running a single process, e.g. vim, rails server, rails console, etc. Panes can be oriented either vertically or horizontally and resized as needed.
Now you might be curious about what my screen looks like with so many possibilities between sessions, windows and panes.
As a Rails developer what I found to be working for me is to have vim in a first window along with a right-side pane for committing code to Github or running tests. Any background process, like the rails server, workers or Elasticsearch, is running in an additional window, together with the rails console.
Some commands to remember
Below is a list of the most important commands I use on a daily basis. It might feel overwhelming at first, but you will get the hang of it sooner than you think. Believe me!
By default, windows will open in the directory of the current session. This will allow them to open in the directory of the current pane:
You can create and split panes in a more intuitive way by adding the following configuration, making sure that it remembers the current path as well:
Which turns on these key bindings:
Adding the following configuration allows you to navigate your vim splits and tmux panes at the same time by using the keys
Ctrl + h/j/k/l, so no more need for the prefix with these ones:
You can resize the active pane with
Shift + L/R/D/U(which refers to each of the arrows keys). The related configuration to enable those is:
I find it also very useful to focus on the contents of a single pane temporarily and unzoom as needed. The
<prefix> zcommand acts as a toggle to both zoom a pane and unzoom. Try it out!
Now it’s your turn! After these notes, I think you are ready to start playing around with tmux, which might be hard at first. My best advice is to not think about it too much - just go for it and stick with it!Read more
We’ve been documenting the effect of stereotypes and bias in relation to issues of race and gender for a long time. When students are primed to believe that boys are better than girls at math, for example, the boys will outperform the girls. But when they’re told boys and girls are equally capable at math, the scores even out.
As software engineers, we’re often faced with the stereotype that technology is the polar opposite of the communications world. Just look at how engineers are portrayed in the media - from HBO’s Silicon Valley to the Big Bang Theory, it’s almost like poor social skills are a prerequisite for doing our job.
At the same time, marketers and business people are told that technology is a “hard” skill while they are “soft” skill experts. This fosters an environment where business folks fail to develop basic technical knowledge that could greatly benefit their career.
The good news is: We can outsmart stereotypes. Let’s throw away the notion that communication skills and technical skills are incompatible. Instead, let’s accept that we live in a collaborative digital world in which both skill sets have an equal and important place.
But seriously, why should engineers care about “soft” skills?
Ok, we all know that coding is all about sitting alone in a dark room hacking at a mainframe, right?
Of course not. These days, big projects are accomplished by teams of engineers, designers, business types, and financial stakeholders. We’re constantly communicating with members inside and outside our team to establish workflows, give feedback on code, create mockups, finalize requirements, establish timelines, and conceptualize codebase architecture.
Effective communication allows everyone to get their job done efficiently - with minimal missed connections and unnecessary back-and-forths. It means setting expectations for everyone around you, allowing business owners to allocate resources appropriately and plan their own projects around accurate development timelines.
Regardless, even if you DO want to hack the mainframe, there are countless awesome projects you can tackle as a technical person with superb communication skills. For example, when brainstorming a title for this post, I thought back to my enterprise security marketing days. Social Engineering is an attack vector that relies on human communication - tricking the doorman into letting you into someone’s server room, for example.
Clearly, when you’re a software engineer AND an expert communicator, world domination is right around the corner.
Your Communication Skill Set
A process by which information is exchanged through a common set of symbols, signs, or behavior. - Merriam-Webster.
Embracing this parallel allows us to apply the same concepts we use to get better at programming to build our skills as great communicators.
It also means that in the end, like programming, we can improve by following reusable, predictable patterns and guidelines. It just takes a bit of conscious time and effort, and the realization that “soft” skills are a key asset in our professional toolbox.
Here are 3 focus areas that can make a significant impact for software engineers:
Jargon just means language that is not well understood outside of a specific context. As software developers, we often forget how many of our words and phrases constitute technical jargon. We casually throw out words like database or the names of services like GitHub or AWS all the time. And in engineering circles, that’s fine!
But what happens when you’re trying to explain a project to one of your designers, a marketer, or your CEO? Jargon becomes a big issue.
- Be aware
- It sounds cliche, but this is the best thing you can do to avoid overuse of jargon in non-technical contexts. Just watch yourself, be aware - if someone looks confused, ask them why, and see if technical jargon is the culprit.
- When you discover a piece of jargon and a nice non-technical translation, write it down! Maybe create a little command line program for yourself to save the translations and look them up later.
- Know your audience
- Do you need to give a presentation to the marketing team? A designer? A venture capitalist? Your audience might use jargon of their own, and if you can learn it beforehand and use it correctly, you can boost the weight and clarity of your message accordingly. For example, maybe the business folks at your company speak in terms of ROI and KPIs - it’s up to you to find out.
Grammar & Syntax
How many of us have accidentally sent out a really important email to a really important person, only to realize one second later that it contained a super embarrassing grammatical mistake?
…and why was that experience horrifying?
Because it makes us look stupid!
Especially with our native language, grammar is the easiest and hardest thing to get better at all at once - mainly because we take it for granted. The truth is, most of us haven’t studied the language we speak and write in for many years, and there are words and rules we certainly knew back in grade school that we no longer remember today.
How to improve:
Sitting down with a book on grammar, a thesaurus, or an online writing tool is the equivalent of sitting down with the Ruby documentation or a book on programming style. Doing so will help you sound more intelligent by making your sentences clearer and your vocabulary more precise. (See, it’s that easy!)
No but seriously, the hardest part is just taking the time to do it.
The word tone literally pertains to the rising pitch of your voice. Tone has a significant impact on the quality of our communication, because the same words can be interpreted in very different ways depending on the pitch of your voice.
Was your comment offensive, friendly, angry, helpful, or sarcastic? Will this create more work for you later, because so-and-so needs to have a sit down talk about the tone of your latest email?
How to improve:
- Read Aloud
- One of the best ways to improve tone is to read your thoughts aloud. Even better - read them to a friend, and see how they interpret your tone. This is especially important when working with a second language, as tone can be highly dependent on cultural norms that may not be familiar to you.
- Style affects tone, and improving writing style follows similar rules to refactoring code. Keep sentences short (8-12 words), leave white space between paragraphs, use punctuation appropriately, and use special formatting sparingly.
- Even when writing, your emotions will come out in the tone of the language you use. If you’re feeling emotional - overly excited, angry, or nervous - it’s ok to put off an in-person meeting or important message for a day. If you absolutely need to communicate immediately, write your thoughts down, read, and refactor, making a conscious effort to come across in a tone that works to your advantage.
Now we loop back to what all this work comes down to: setting expectations. When we communicate effectively, the people we work with know what to expect from us and our team. Projects move forward with the resources they need, and we can all get our jobs done efficiently.
This isn’t about how you say something, but WHAT you say.
How to improve:
- Clarify requirements
- A lot of people really suck at communicating, and we can accept and work around that to our advantage. This is especially true when non-technical people give project requirements, and your biggest task in this scenario is to ask questions.
- Say “I’ll get back to you”
- Figuring out how to estimate software projects takes time and mental effort. Give yourself time to think. If someone comes to you asking for an estimate or your thoughts on a new project, practice saying, “I need to look into X, Y, and Z - let me get back to you on that”. Research done upfront can help you avoid time-intensive backtracks down the road.
- Continue communicating
- Especially with software projects, it’s not until we dive into the codebase that we figure out how long something will take, and that’s ok. Just remember that as software developers, we are often the ONLY members of our team with access to the codebase and the ONLY ones who understand this aspect of our job. It’s therefore our responsibility to communicate what’s going on, as soon as possible. Never feel guilty for bringing up that a project will take longer than you originally thought - so long as everyone knows what to expect, deadlines and resources can be moved around in time.
Can you update some website copy for me?
Sounds great. Where is that copy? Can you show me that page on the website? Do I need to write the copy? Does this need to be reviewed? Will this copy change again in the near future? Does it need to be up on the staging website first? Is this copy saved as text, or is it an overlay on an image somewhere…?
Tomorrow’s TODO List
Communication skills can be improved with just a small amount of effort on our part, and it’s something we can work on over time - just like learning a new programming language, or picking up Vim.
- Call the least tech-savvy person you know - Explain your latest project, then ask them to explain it back to you. Did they really “get” it? Did you find any words for your jargon translator?
- Read your docs - Skim a grammar guide for concepts you forgot you knew.
- Learn a new vocabulary word - Find a word that is a more precise version of a word you’re using now.
- Estimate coding time - Take a guess at how long one task will take you, start to finish. Compare after your production deployment, and see how well you did.
In the end, my hope is to break down the “soft skilled people” vs. “hard skilled people” stereotypes, and instead focus on how both sides can foster an environment where technically skilled, communicative developers can more efficiently build bigger, better collaborative projects.
This blog post was adapted from my talk at NLHTML5, and you can check out the slides here.
Don’t forget to also follow us on Twitter @SpringestOps, where we practice our communication skills on the regular.Read more
- Be aware
subscribe via RSS