Booty Pirates and GeoLotto
A note to our customers :
As we explained in our earlier email[s] to you, Geonomics Global Games Ltd and Geo24 UK Ltd (the companies behind Booty Pirates and GeoLotto), were acquired by ZEAL Network SE on 30 March 2016. Zeal Network has decided to shut down these UK games and, as a result, your account with Booty Pirates / GeoLotto has now been closed.
Where possible, we have automatically refunded any outstanding balances in customer accounts. If you have not yet received a refund, and you believe that you had an outstanding balance in your account, we might not have been able to process your refund automatically. This might be because we need you to provide up to date contact and/or bank details, for example.
To arrange any refund which is due to you, or if you have any other questions in relation to the closure of your account, please contact the Player Support Team, who are available on 0800 684 8710 from Mon-Sat 8am-8pm (except for Bank Holidays). Email queries can be sent to firstname.lastname@example.org.
Once a player account has been inactive for a period of 12 months, and the account holder has not requested a refund of any outstanding balance, we will donate any such outstanding balance to charity.
If you have already received your refund or contacted the Player Support Team no further action is required.
Markov Chains and our Games
Geonomics conferences attended 2015
At Geonomics we value the continuous improvement and personal development of everyone on the team, and we are always looking for ways to improve our processes and working practices. To this end a number of our team members have attended conferences, talks and events which you can find out more about below.
Chrome Developer Summit
Lewis attended this event in November. As the name implies the focus was very much on Google Chrome and discussions around a lot of the new features that are being built for the browser such as Web Service Workers to enable better offline experiences. There was a big emphasis on improving web app performance and Lewis came away with a number of short term and longer term practical points for how we can improve the end user experience of our products:
- Ensure all images used by our apps are losslessly compressed as part of our build pipeline
- Target a 1 second load time for all our pages, and investigate deferred loading of resources
- Target a frame rate of 60 fps for our canvas animation code
David and Lewis went to the two day JAX conference in October. As with Devoxx, there was a big focus on microservices and Java 8 features. It was gratifying to discover that a lot of the best practices (such as having a static analysis phase in our build pipeline) and new features talked about during the two days are already in use here at Geonomics.
One area in particular that we had already been looking at was ORM vs native queries. David did a lot of work over the last year to learn more about improving database query performance by using less well known query language features such as the OVER clause and WINDOW functions and spreading this knowledge to the rest of the team via our regular Developer Learning Lunchtimes. As a result of this we now always consider whether or not to write a given query in Hibernate or native SQL to provide the best performance we can. For example, one of the queries we use for tracking when players made their first wager on the site vs when they made their first wager in each individual game makes use of PostgreSQL WINDOW functions. This would not have been possible using a Hibernate query. Instead we would have had to load the data into memory and process in Java.
One of the talks that Lewis found most valuable was on how we can apply the “automate everything” principle of continuous integration to non development areas of the business. This was an ever useful reminder that we can always strive to improve efficiency and productivity by automating manual tasks and processes. We already use Jenkins to automate as much of our daily release process as possible, including not just the code compilation part, but also generating email reports about which feature flags are being turned on for that release and detailed reporting about our Selenium tests. Whenever we introduce new processes, our general approach is to first do them manually. Once we have ironed out the kinks and matured the process then we automate as much as we can.
The focus on Java 8 was particularly interesting for us. Before Java 8 was released back in 2014 the dev team at Geonomics considered migrating to Scala from Java 7. We had concerns at the time regarding Scala’s compile times and complexity. It also seemed that many of the beneficial features of Scala would be included in Java 8. All of the developers on the team weighed in and the consensus was to wait for Java 8 and continue using Java. It was good to see that the Java community has embraced Java 8’s new features. Of course, Lewis is already looking forward to the future release of Java 9, in particular the introduction of value types.
The Lead Developer conference
Luke, Prem and Paul N attended this brand new conference in September. The single day conference focussed less on purely technical topics and more on how to be a good team lead and dev manager.
The conference was particularly timely for Luke, one of our developers who was just about to become a team lead. It really highlighted for him what challenges to expect in the role, such as a greater need for rigourous time management, how to deal with what motivates people, and a less purely technical focus when it comes to personal development. Because most team leads at Geonomics joined first in a technical role Luke has access to people who have been down the path he is on and can offer practical tips and advice, in addition to more formal training such as the management training course he recently went on.
The dev team lead role at Geonomics one is a broad one. First they must be an excellent developer. We believe the most effective dev managers know how to deep dive into the code just as well as the people they manage. Second they must be able to effectively manage people. Team leads need the ability to motivate and encourage the people on their team, help their team members with their own career and skill development, and give constructive feedback when something needs to be improved. Third they need to be effective project managers, acting as scrum masters and making time to deliver vs scope trade off decisions to keep our products moving forward at a fast pace.
For Prem and Paul N, two of our more established dev team leads, one of the main takeaway points was that to continue adding value as a team lead the focus becomes less on learning new technologies and more on improving other non-tech skills such as:
- People management. One of Paul N’s favourite talks was from Sam Barnes on how you can never use yourself as an example of what is “normal”. Everyone is different and people have many different motivations which need to be taken into account when managing them.
- Improving productivity. The excellent talk by Camille Fournier made the case that cloning yourself is not an option. A team lead can improve productivity by “training their replacements”. This enables effective delegation and trust that the right things will get done, regardless of which member of the team is doing the task.
- Effective prioritisation and judgement. Team leads and managers are often faced with seemingly mutually exclusive options such as writing high quality code while also meeting tight deadlines. Patrick Kua gave a talk on how to deal with apparent paradoxes, advising on finding the right balance between conflicting requirements and how this balance can and should change over time.
Overall this was a really valuable addition to the yearly tech conferences held in London and we’ll definitely be sending people again in 2016.
Kayhan and Paul L attended this long running Java conference in June. As was a theme at a lot of the conferences we attended this year, microservices took centre stage. Having switched to a daily release process early in 2015, we can definitely see the value in having smaller single responsibility components to enable us to release changes to production even more frequently. For those who have been living under a rock, “microservices” is a term applied to building complex applications from small decoupled components that talk to each other using language agnostic APIs. It’s pretty difficult imagine how an application will grow and ultimately where code responsibilities should lie when working in a fast-paced startup where product requirements are changing continuously. As such our codebase has grown predominantly as a monolith initially, an approach recommended by Russ Miles in his “Highway to microservices hell” talk at the Lead Developer Conference. Once the broader scope of the entire application is more well defined, then it can be broken down into smaller independent services which is on our architecture road map.
One of Kayhan’s favourite talks was about the information your continuous integration server is giving you about ways to improve your application architecture. The techniques discussed don’t help us very much when our application is a monolith, but they can definitely help us as we migrate towards a more modular application architecture.
London Technology Week – Coding & Caffeine: The Search For Technical Talent
Matt Young, our CTO, attended this talk from Joel Spolsky (of Stack Overflow fame) in June. One of the key points to come out of the talk was that attracting good candidates is not something that starts and ends with an “HR person”. Everyone on the tech team is responsible for creating an engaging and attractive place to work, with a good technical culture.
So what are some of the qualities we believe create a good technical culture?
- Positive attitude. Any seasoned developer can look at a new codebase and point out a whole bunch of things that aren’t great about some aspect of the code. What we value is people who can come up with and implement a plan to continuously improve our code.
- Desire to learn. Nobody is perfect, no one has all the answers. We greatly value people who are self aware enough to know what their relative weaknesses are and motivated to learn and improve their own skills. If they can do that while simultaneously improving the skills of those around them then even better.
- Communication skills. Being able to communicate clearly and concisely, both verbally and in writing, is incredibly valuable to us. This is particularly important when working with a remote team for whom English is not their first language, as discussed below.
- Ability to handle pressure. Sometimes things go wrong, it’s a fact of life. We value people who can keep their cool in such situations and deal with the immediate problem by thinking calmly and quickly through what went wrong and how to fix it. They can then come up with a solution to ensure that the particular problem or class of problems can never happen again. And they can do it all without feeling the need to shift the blame onto someone else.
One of the subjects touched on during the talk was remote working. We have an excellent QA team here at Geonomics, who just so happen to work in Ukraine and Russia. We have no doubt that our products are of a significantly higher quality than they otherwise would have been due to their contribution. The fact that they are not co-located with our developers does however present challenges when working on projects together. One of the biggest benefits of working in a co-located group is the ad-hoc discussion that can often occur that can see the seed of an idea turn in to a whole new product direction in a short space of time. The final outcome of such a discussion is of course communicated to all relevant parties, but the journey towards that decision or outcome is often lost for some team members when working in a distributed team. At Geonomics we work hard to ensure that both the why and the what of a piece of work is clearly documented for all team members to see, regardless of location.
Mykolas attended this single day event in April. Cassandra is a very interesting technology, offering an elegant solution to traditional problems such as the database being a single point of failure and it being difficult to scale. The ability to scale performance linearly with each node is extremely attractive (although it may come at the cost of latency). One of the big downsides in the context of our games is the “eventually consistent” nature of the database (see CAP theorem). As our games are real time in nature and one player’s wagers may affect the choices of another player we value consistency and having ACID transactions so that all players can see every other player’s actions in close to real time. As such Cassandra isn’t really suitable for our main game platform, but it’s useful to know that the technology is there should we have any future applications where availability and resilience are valued to a greater extent than real time consistency.
Sound like a place you want to work?
We’re always on the look out for talented and enthusiastic software engineers to join our team. If you’re interested in working with us then send us your CV and an optional cover letter to email@example.com. You can read about our interview process here, here and here.
The Learning Machine: Our Custom Version of Agile Explained
“Agile” is one of those horribly overused words in the IT industry that seems to mean different things to different people. Not all of those things make a lot of sense to us. (Our CTO once attended a tech seminar where a speaker asserted that “agile waterfalls are a red herring when you’re creating internal start-ups”. He speculates that this might be some sort of kōan, but the rest of us think it’s just a winning line in buzzword bingo.)
A Fair Toss?
“Heads or tails?” The next time you’re asked that as a coin flips through the air, perhaps your reply shouldn’t be as simple as “heads” or “tails”. We explain more.
Humans have been deliberately using randomness for thousands of years. Besides fun and games, it’s widely used to allocate tasks and resources in ways that affect us all – from being selected for jury duty to drawing the short straw on doing the chores at home. Some have even used it to attempt to divine the will of the gods – though in modern times such cleromancy has itself spawned games and amusements, including notably the Magic 8 Ball. We all have an intuition about how randomness “works” (though our intuitions can often be wrong – as with Monty Hall’s goats) and most of us study at least the basics of probability at school. But how much do we think about how fair a random event is – even something as simple as tossing a coin? And how does that relate to the (quite literally) laser-powered electronic random number generators we use at Geonomics?
To generate the random outcomes in our games we use Swiss “Quantis” random number generators. These are pretty well-regarded pieces of equipment. Lots of people – including the Swiss Federal Office of Metrology (metrology being the science of measurement, but you knew that, right?) – have put the boxes through their paces to check that they really work as advertised. (We also test them ourselves using the “diehard tests” created by an American professor of statistics called George Marsaglia. Those tests are not to be confused with any films featuring Bruce Willis.)
So how do they work? Inside each Quantis box is a laser. It fires a single photon at a time at a half-silvered mirror. There’s a detector on the other side of the mirror. So there’s a 50% chance the photon will pass through the mirror and be detected. Quantum mechanics tells us – by which of course we mean “people who understand quantum mechanics tell us” – that this is a fundamentally random event. In other words, there’s no way of knowing in advance whether any given photon fired at the mirror will pass through to the detector. Put simply, the box performs a quantum mechanical electronic coin toss.
By firing lots of photons in succession, we can generate a random sequence of “photon” “no photon” (or “heads” and “tails”, or “0”s and “1”s or anything else you want to call the results). From such sequences we can obtain larger random numbers. (Of course, when we say “larger random numbers” what we really mean is “a randomly generated integer within the range from 0 to N – 1 inclusive, where N is some integer chosen according to our needs and larger than 1”. But if you go around saying things like that too much, you stop getting invited to parties. And, in any case, you know what we mean.)
Some readers will by now be getting excited about an inherent flaw in any laser photon quantum coin tossing device. Such readers will be jumping up and down saying “There’s no such thing as a perfectly half-silvered mirror. Your two possible outcomes will not have exactly the same probability.” And some of these readers – which is to say a subset of the first set of readers who were getting so excited – will already be saying “And I know how to fix it”. In other words, they know what’s coming, and can skip the next few paragraphs.
For the rest of us, the thing that some of the people who aren’t reading this paragraph were getting so excited about is what’s often known as “the biased coin problem”. The name comes from the glib way of phrasing the issue as a brain-teaser to annoy your friends with over dinner. (Or down the pub or wherever it is you go to annoy your friends.) Anyway, the brain teaser goes as follows: “Imagine you have a coin which, when you toss it, has a very slightly different chance of landing ‘heads’ than ‘tails’. You don’t know which outcome is more likely, or how much more likely it is. You just know that it’s constant difference. It could, for example, be 51% likely to land ‘heads’ and 49% likely to land ‘tails’. Or, to take another example, it could be 50.002% ‘tails’ and 49.998% ‘heads’. How can you use this biased coin to make an exactly 50:50 random decision?”
Often people will start from wanting to measure the probabilities of each outcome of the coin toss. This approach will give you an approximation of the probabilities. And if you toss the coin a few million or even a few billion times, then your approximation should be pretty accurate. But even then, how do you use what you’ve measured to generate two possible outcomes, each of which has exactly the same probability as the other? (See how we reworded the question slightly?)
There’s actually a simple answer. You don’t need to know the probability of “heads” or “tails” (or “lands on its edge” or “falls down a drain” or “is plucked out of the air by a quick-witted magpie”). Imagine tossing the coin twice in a row. The probability that you get “heads then tails” is exactly the same as the probability you get “tails then heads”. If you get anything else, eg “two heads” or “two tails”, you just toss the coin twice more – keep doing pairs of tosses until you get “heads then tails” or “tails then heads”.
If your friends don’t mind doing a little more maths (or “having a bit more fun” as your maths teacher might have put it), you can now pose a supplementary question: On average, how many times will we have to toss the coin to get an outcome that we can use? (Mathematicians, including your teacher, would call this the “expected number” of coin tosses.) In principle, this is the sum of an infinite number of things: “two times the probability that we need just two tosses” plus “four times the probability we need exactly four tosses” plus “six times the probability we need exactly six tosses” plus etc etc etc, with each extra term getting smaller and smaller. (It’s astonishingly unlikely that we’d need to toss the coin 100 times for instance unless it’s very biased.) But, with a little bit of algebra, we can work out an exact answer to this infinitely long sum.
Let’s use “p” for the probability that the coin lands “heads” and “q” for the probability it lands “tails”. (If it’s never going to land on its edge or be eaten by a magpie then q = 1 – p, but that’s not important at this stage.) Let’s use “t” for the expected total number of coin tosses to get a result we can use. The probability we need just two tosses is pq + qp = 2pq. The probability that we need more than two tosses is then 1 – 2pq. If we do need more than two tosses then, after the first two tosses, the expected number of additional tosses we need is also t – because we’re “starting again”. (This neat insight comes to us courtesy of a paper by Harvard Professor of Computer Science, Michael Mitzenmacher.) So now we can write a formula for t:
t = 2 . 2pq + (1 – 2pq) . (2 + t)
Expanding this out we get:
t = 4pq + 2 – 4pq + t – 2pqt
Which simplifies to:
2pqt = 2
Which we can further simplify and rearrange to:
t = 1/pq
This simplified formula enables us to answer the supplementary bit of the brain-teaser. If the probability of “heads” and the probability of “tails” are both “about a half” then, on average, we expect to need only about four coin tosses to get fair 50:50 outcome using the “pairs of tosses” strategy above. In other words, if you were using this method with a laser randomness generator, then, as long as your mirror is approximately half-silvered, you’re typically not going to require too many photons to be fired at it to generate each “electronic coin toss” outcome. And, since photons travel at, well, the speed of light, you can each generate literally millions of such binary outcomes per second. (Quantis actually do their statistical norming in a slightly different way for various reasons, but we’ll leave the details for a future blog post.)
So, now we know about de-biasing photon detection in laser-powered quantum-mechanical electronic coin-toss boxes, what’s our new answer to the original question “heads or tails?” Well, as long as the person asking isn’t likely to be moved to physical violence by a harmless bit of pedantry, we might say “Since your coin hasn’t been tested for bias by an independent metrologist, I propose paired tossings with only different outcomes for each toss being deemed valid. And I call ‘heads then tails’.”
Having a fast and reliable generator of random numbers is a key part of how we ensure our games are fair for all players. If you’re interested in probability then you might like working at Geonomics. Check out our careers page.
The Good Ship Booty Pirates: The Maiden Voyage
We know, we know, it’s been a while since our last blog – but we haven’t lain furlough. In fact, we’ve been busy disrupting the traditional gambling space to launch our latest product, Booty Pirates (if you’ve been playing it, let us know what you think).
We’ve talked before about innovating in the space sitting between social gaming and softcore gambling, using the best of both worlds to inform an original new game that players will love. The game was launched a few weeks ago, in our trademark, lean/agile/[insert latest Beta buzzword here] way and we’ve been working hard ever since to get it exactly right. That’s why we’ve developed our own feedback loop system we’re calling ‘The Learning Machine’, where we test and iterate in weekly cycles. This might explain why we’ve been so busy.
Booty Pirates is our attempt to harness the very best of social gaming – things like multiplayer functionality, competitive league boards, player chatrooms, and character role-play and so on – and reframe it within the context of gambling. Playing to win for instant cash prizes is a key feature, naturally being the trademark or draw of soft-core gambling games like bingo and online casino style games. The ‘gangsta pirate’ narrative we’ve introduced to Booty Pirates brings a narrative-driven and hyper-competitive dimension to the existing games in our portfolio: now our players join Goldbeard’s crew and actively seek out treasure on a map, competing against one another (as historical pirates once did) in their quest to acquire as any pieces of eight/dolla dolla bill.
We want our players to always have fun with our games – and hopefully win some money along the way. With Booty Pirates, they are able to do exactly that. It doesn’t hurt that we now have an excuse to talk, dress and act like a pirate (which, to be honest, we never really needed in the first place) and have some plans in the pipeline to get our players involved in that too. Watch this space…
How To Impress Us With Your Tech CV
There’s a lot of advice on the internet about what makes a good CV for an engineering candidate. Unfortunately, as with many subjects, you’ll find that there are a variety of opinions. Rather than attempt to debunk these, we thought we’d list our advice for putting your best foot forward in a job application to Geonomics.
Make it easy to read and process your CV. It’s a small amount of work and can make a big difference in the impression your CV makes. It also helps show you’re serious about considering a new job.
- Send your CV as a “.doc” or “.docx” Word document or as a PDF document. In either case, make the file name the same as your name. That’s more useful than calling it “cv.doc” or “résumé.pdf” as it helps us distinguish it from other candidates’ CVs.
- Pick a sensible font and font size. Sure we can zoom in and out on the screen, but the easier your CV is to review, the better. We do print CVs out — eg for candidates we’re going to interview — so make sure it looks good when printed as well. If you’ve put everything in 8-point Arial Narrow, then your CV will be hard to read.
- Put your name and contact details (email address, phone number, postal address) at the top of the document. You don’t need to put titles such as “CV” or “curriculum vitae”. And, unless you’ve got an incredibly common name, we don’t need all your middle names.
Bad — extra words don’t add anything Good — concise yet still clear CURRICUM VITAE (CV) OF CHRIS BOBBIE ROWAN DAKOTA BABBAGE
ADDRESS: 123 The High Street, Somewhereville, Countyshire, AB1 2CD
TELEPHONE: 07123 456 789
123 The High Street, Somewhereville, Countyshire, AB1 2CD • 07123 456 789 • firstname.lastname@example.org
- Keep the length down to 2-3 pages. If your CV is longer than 3 pages, we’ll find it hard to get to the end unless it’s really gripping. If you’ve got the content right (see below), it’s unlikely the CV will need to be longer than 3 pages anyway.
- Don’t write a cover letter that repeats what’s in your CV. Even worse, don’t omit key facts from your CV on the grounds that they are in your cover letter. The CV is the most important document and we usually look at it first. If that’s missing key info, we may not even read the cover letter. In any case, a cover letter isn’t essential. If you do want to write one, use it to tell us why you’re keen to work at Geonomics.
In some ways, the way that you write your CV is just as important as the content. Our teams work really well together and that’s partly because we hire good communicators. You don’t need a line in your CV telling us that you’re a good communicator or have strong attention to detail — instead, show it to us by communicating well throughout your CV.
- Make sure what you write is clear and unambiguous. Get a friend to read your CV to see if they understand it all. We’re not overly worried about how idiomatic or grammatically correct your English is but if we can’t understand what you’re saying, or the meaning is ambiguous, then how do we know you’ll be able to communicate clearly with your colleagues?
- Get the details right. You’re applying for a technical job where a typo in a source code file or shell script could cause a bug or outage. Demonstrate your attention to detail by proof-reading your CV. Use a spell-checker. If you’ve put hyperlinks in your document, check they work. If you’ve used technical terms, look them up to check the capitalisation. Then proof-read your CV again. And maybe one more time for luck.
There are some key things that we’re looking for on your CV. If they are not there, but your CV is great in other respects, then we might come back to you with questions. But otherwise we’ll probably make an assumption instead. And our assumptions might be a bit pessimistic. (For instance, we might assume that the reason you haven’t told us about that year-long gap between two roles is because you were doing something shameful involving cross-border telesales of unlicensed financial products. It’s better that you tell us up-front what you really did.)
- The most important content on your CV is your career history and your education details. Spend your time getting this right.
- Give us start and end dates for each job and each period of education. Month and year is fine for each date. (Year by itself is too vague. At the extremes, “2012-2013” could be a two year stretch or a short period from Dec 2012 to Jan 2013.)
- If you’ve got a degree, tell us your degree grades. Otherwise, it looks like you just scraped a pass. If you graduated within the last five years, then tell us a little bit about your course (not every module but the bits you enjoyed most) and also let us know your A-level (or equivalent) grades.
- If there are gaps in your career/education history (other than the odd month here or there), explain what you were doing so that we don’t have to make an assumption (see above).
- For the role descriptions, unless they were particularly unusual, the day-to-day responsibilities of the job aren’t that interesting to see. We know what a typical Software Engineer job or Systems Engineer job entails, so you don’t need to tell us that you “fixed bugs” or “deployed software” or “used such-and-such ticketing system”. Instead, focus on what your contributions and achievements were. Imagine you’re talking to a friend or a colleague and you’re telling them what you are most proud of having done in that role.
- Try to be specific—tell us facts and details rather than trivia. If you improved the way backups were done, give us a measure of how much better they became (X% faster, Y fewer hours per week of manual process, Z% more coverage etc). Don’t get lost in unimportant details (what model tape drive you replaced, the exact distance from your office to your data centre, etc).
- In a similar vein, don’t be vague about what your role was. Lots of candidates tell us they were “involved in such-and-such project” or “participated in meetings about some project”. Those sorts of phrases make it sound like the level of your involvement was quite small: maybe you made tea or helped keep a chair warm in a meeting room. Your contribution was bound to have been more substantive than this, so tell us what it was.
Things to leave out
You don’t need to use up space with information that’s not going to help us decide whether to hire you. If you need one of the sections below because a recruiter has asked for it, then it’s fine to have it—but we probably won’t pay much attention to it.
- Photos and random facts. We’re not hiring actors or models, so we don’t need your photo. Nor do we need to know whether you have a driving licence, what your marital status is or what your favourite film is. None of these things will affect your ability to do the job.
- Long lists of skills. If you tell us you are “expert in Technology X” or rate yourself “7/10 on Framework Y”, it doesn’t count for much. It’s so subjective. You probably know someone who thinks they can sing brilliantly in the shower but who’s never going to get a record contract. We would much rather see from your role descriptions where you used a particular technology and what you did with it.
- Profiles and Personal Statements. Unless you’ve got something particular to highlight, don’t write a lot of boilerplate. We’ve seen hundreds of variants of “I am a self-motivated fast learner who is dedicated to achieving great results, keen to advance my career and a great team player who is also capable of working well by myself”. It doesn’t really add value to your CV.
- Long sections about your personal interests. We want you to you have a life outside work. It’s a good thing. How much of it you put in your CV is a different matter. If you’ve achieved something outside of your education/career which shows us what a strong character you have, that’s great to see. Equally, if, in your spare time, you regularly contribute code to the Linux kernel, then that’s also interesting to us. But most people enjoy “socialising with friends” and “watching films” so you don’t need to highlight that to us. If you can’t think of anything stand-out to put down as an interest, don’t worry—we’re not going to think you’re boring.
A Day In The Life Of A Geonomics Developer
We’re often asked what a typical developer’s day here is like. We asked Doogal (aka David Simpson) to jot down his thoughts.
It’s Friday morning. I’m on the Central line. It’s hot, crowded and I’m surrounded by people in suits with shiny hair. I’m wearing a pair of comfy shoes, shorts and a t-shirt I got from a music festival 7 years ago. I earn about as much as these suited people and it fills me with glee.
I get in to work, lose the shoes, grab food from the free breakfast items in the kitchen and sit down with a colleague and have a chat about the best way to structure a Pirate Selector over breakfast.
After stand-ups I get cracking on making coins flip out of our little pirate character when he wins something. It’s good fun, it’s all new code, it’s well written and I’m dead proud of it.
Then lunchtime hits and I go to the pub with a bunch of friends who I also happen to work with. Someone mentions they’re having an issue with SQL (it’s kind of my niche) over lunch so when I get back I sit down with them and we figure out a solution.
I spend the afternoon writing a piece of code which scatters pirates off the map in a somewhat whimsical way at the start of a new game. It’ll be in production tomorrow, so I’ll be able to log on to chat and actually ask our users what they think of it.
The end of day rolls around and the kitchen has filled up with people. Some are playing pool, others are on the xbox, the rest are just chatting and eating crisps. I have a chat to James (our CEO) over a beer about an idea I think is cool.
A bit later on some people are playing board games. I decide to head home, grab a Chinese and get back to the flat.
All about Geonomics developer remote coding test
As you might expect, part of our developer recruitment process involves applicants writing some code for us. We want to give you a chance to show us your coding at its best, working on a problem that’s large enough to be interesting but small enough to be completed in a relatively short time. We don’t want you to be under time pressure doing some web-based test; we would rather that you used the tools and environments you’re already familiar with and do things at your own pace. For instance, even though we suggest you spend only a couple of hours or so on the problem, you might want to spread this out over two to three days. Hence we’ll email you the problem and ask you to email back your solution once you’re happy with it.
Typically we ask you to write a program that generates answers for some small puzzle problem across a range of inputs and within a performance bound. Meeting those requirements is only part of the story however. We are looking for “well-written” submissions, by which we mean code that avoids unnecessary complexity, is clear and concise without being overly terse, has had some thought given both to usability and to extensibility, handles edge cases (including guarding against invalid inputs) and has some sensible unit tests. In short, the tech test is an opportunity for you to show us that not only can you solve the problem, but also that you can write beautiful code.
How to tackle our remote coding test
- Take the time to fully understand the problem you are solving.
- Think about code structure and how your algorithm will work.
- Come up with an initial version that solves the problem.
- Spend some time improving on your initial version by considering “non-functional” and “edge case” requirements.
- You can use tools like maven or gradle if you would like to. The .zip or .7z file you submit to us should include all of your source code and everything we need to compile and run your code.
- We will run your compiled program against a range of inputs, not just the one mentioned in the problem specification.
- There’s no time limit so take the time to show us your best quality production code.
What will happen after you submit your solution?
- One or two of our developers will run your program against a range of sample input files and input parameters.
- If it generates correct output sufficiently quickly, they will then review the source code of your solution. (Code review is a big part of how we work at Geonomics and all of our developers are skilled at providing constructive feedback to their colleagues to help us all write the best code that we can.)
- Once this is done we aim to get back to you with a response very quickly – usually on the same day but no later than the next working day. If you have applied through a recruiter then we will send our response to them. If you don’t receive any feedback by the end of the next working day don’t hesitate to get in touch with us. We may ask you to do a phone interview at this point if you haven’t already done one or we’ll invite you to our office for some face to face interviews.
How to ace a Geonomics developer phone interview
At Geonomics we place a high value on developers having excellent problem solving skills, great understanding of computer science fundamentals and the ability to reason about concepts clearly and concisely. Our phone interview is designed to test you on these things. If you follow the tips in this article then you should have the best opportunity to demonstrate your skills and knowledge to us – which is what we want.
Preparing for the interview
- Do your research – check out the rest of our website. This shows interest in Geonomics, and it will also help you form questions for the phone interviewers so that you can learn more about us.
- Brush up on your computer science fundamentals, data structures and algorithms.
We don’t expect you to have read the whole of the CLRS Algorithms book or even Aho/Hopcroft/Ullman’s Data Structures and Algorithms, but you’ll probably be the sort of person who’s at least interested in the contents of both. And, whilst, unlike some employers, we won’t ask you about the sbrk() system call, you should certainly be comfortable in, for instance, explaining the difference between the stack and the heap.
- Think about any questions you want to ask us about who we are, what we do and how we work.
On the day
- Find a quiet, comfortable place to take the call. (If you’re taking the call on your mobile, check that it’s somewhere you’ll get a good signal.) Try to be in an environment where you feel comfortable solving problems. If you’re in a busy or noisy area, it’s going to be hard for you to concentrate and difficult for your interviewers to understand you.
- Have a pen and paper ready. It’ll be much easier to think through problems if you have something to sketch or write on.
- Consider using a headset so you can keep your hands free to write down any notes as you go through any problem solving questions.
During the interview
- Two of our developers will call you at the arranged time.
- They will ask you questions on computer science fundamentals, data structures, algorithms and problem solving. We don’t expect every developer who applies to us to know everything already, in fact we will try to keep asking questions until we find something you don’t immediately know as we expect every developer at Geonomics to be able to pick up and reason about new concepts quickly.
- Think out loud. This is critical for phone interviews. Since we can’t see you, the only way we can understand your thought process is to hear you talk.
- Don’t be afraid to ask questions. If anything is unclear about a problem, ask your interviewers – that’s what they’re there for.
Once the interviews have finished asking you questions they will give you the opportunity to ask them some questions in return. Don’t worry about asking the right questions or the wrong questions – this is your chance to find out if Geonomics is the right fit for you.
After the interview
After the interview is over, we aim to get back to you with a response very quickly – usually on the same day but no later than the next working day. If you have applied through a recruiter then we will send our response to them. If you don’t receive any feedback by the end of the next working day don’t hesitate to get in touch with us. We may ask you to do a remote programming test at this point or we’ll invite you to our office for some face to face interviews.