The current position has been filled but if you are interested, you can contact us anyway and we will keep you in mind for future openings.
What we offer
As this document is rather long, first something to motivate you to read on:
- Salary: 720 CZK / 28 USD / 27 EUR per hour (pre-tax)
- Unusually flexible working hours: as long as you do the agreed-upon number of hours each month, we mostly do not care how you schedule them. We also need your (virtual) presence at team meetings (usually weekly).
- Part-time work. You can choose the base working hours in your contract. We usually recommend between 40% FTE (i.e., 16 hours per week or 3.2 hours per workday) and 80% FTE (i.e., 32 hours per week, 4-day workweek, or 6.4 hours per workday). Full-time (40 hours/week) is potentially also available, but we recommend against it, as you hit dimnishing returns of productivity.
- Paid overtime is available by agreement (if we want to achieve some deadline, or if you at some point have extra time or just a lot of energy and want to do more hours). Unpaid leave is available by agreement if you for whatever reason cannot currently meet your contract commitment in a given month.
- Almost fully remote but being in Prague (for occasional meetings/cowork/etc.) is a plus
- 6 weeks of paid leave per year
- One-year contract (not that we would want to get rid of you, but we are financed by grants so the long term future of our organization cannot be guaranteed). We expect to extend it as soon as we get more funding.
- A great deal of developer autonomy and creative freedom (more on that later)
- Work in a small team and informal environment, where things happen quickly and without unnecessary bureacracy
The Confido Institute is a non-profit research institute. We are developing interactive applications and courses to help people and groups better think about uncertainty and communicate it, in order to improve individual and organizational judgement and decisionmaking. Our work is broadly based on the research of Philip Tetlock, summarized in his book Superforecasting. Our work is supported by grants, currently from the FTX Foundation.
You can read more about us on our website.
Our work currently consists mostly of developing web apps but we may add mobile apps in the future. We do not have separate backend / frontend / mobile roles, we expect developers who can adapt to all sorts of tasks (more on that below).
We emphatically do not care whether you know any of the aforementioned technologies, as long as you are willing to learn them on the go and you believe you can.
Instead of requirements: signs you may be a good fit for our team
In our team, we are not looking for specific knowledge or experience. Instead, we are looking for people with a certain set of skills, traits, approaches and mindsets that, in our experience, make for good, productive and fun colleagues.
However, such general high-level traits are rather hard to describe. So instead, we list a lot of characteristics that, in our experience, the people we are looking for tend to have more often than not.
Please note that this is a correlation, not causation. While some of these characteristics are straightforwardly useful (such as the ability to quicky learn new things), some are just indicators of some deeper traits and some are downright silly. Thats why we call these signs, not requirements.
Consider this to be a kind of ‘matchmaking quiz’. Do not worry if you don’t fit some of these points or even disagree with them. The right question is: to what extent does this list as a whole resonate with you?
General personality traits
- You are strongly driven by curiosity. You always want to know how things and technologies work inside. You hate black boxes.
- You have a strong desire to continously learn new things – both in terms of knowledge and skills. You learn new programming languages or techniques in your free time, just for the fun of it.
- You have a wide range of interests outside of programming. For example you are interested in history, do theatre, build electronic gadgets, study languages, etc.
- You love to challenge your mind – solve puzzles, riddles, math problems etc.
- You have the Scout Mindset, i.e., a strong willingness and even desire to change your mind in light of new evidence, even when it is unpleasant, you have to admit you were wrong etc.
- You hate doing things a certain way just because that is how it is always done. You like first principles thinking, as exemplified by Richard Feynman (e.g. in the great book Surely you are joking, Mr Feynman) and later popularized by Elon Musk (but not because of them; you had been doing it long before you first heard this phrase). You have a healthy level of distrust toward all kinds of authorities.
- You hate monotony, repetitiveness and boredom.
- You are kind of a bit lazy. You especially hate doing superfluous, unnecessary and unproductive work, such as writing boilerplate code.
- You are able and prefer to work independently, with minimal oversight. You can be assigned a high-level problem to solve and can yourself split it into subproblems, choose the right tools, do experiments, ask for help, ask for clarification or point out that the assigment does not make sense in some way, that is would take too much effort possibly not worth the result, and in general apply your common sense instead of blindly following orders. If you have read Harry Potter and the Methods of Rationality (a great book btw), the organization of the Chaos Legion is a good image of what we have in mind.
- You prefer experimenting, tinkering, trying things out, learning as you go to carefully planning out everything in advance.
- Most of the points above can also be summerized as having the hacker mindset or being a part of the hacker culture.
- You are a student or alumnus of, or dropout from, a theoretical CS, math, physics or a similar study program. Especially if it is at the Faculty of Mathematics and Physics, Charles University, or an institution with a similar spirit. Yes, we believe that theoretical CS and math students make better developers than students of software engineering. We do not care about your grades or whether you have finished your studies. More importants are questions such as: Did you enjoy studying this kind of things and solving this kind of problems? Do you feel that you have learned some new ways of thinking and problemsolving in the process?
Your approach to software development
- Thomas Aquinas said beware the man of one book. Scott Alexander famously said beware the man of one study. We say:
- Beware the man of one paradigm. If you think that object oriented programming, functional programming, unit testing or anything else is the answer to everything and people are just not doing it enough, you probably won’t be a good fit. If you think these are kinda good ideas that sometimes get overused and/or overhyped, you’ll be okay.
- Similarly, although we will be doing mostly web development, we prefer people whose background is not exclusively in web development, as this makes it harder to see with fresh eyes. In fact, no background in web development is strictly required, although some experience may be useful.
- You care about both pragmatism / getting things done and elegant design. These often go together, but when they don’t, you try to strike a reasonable balance between them.
- You do not think that good programming consists of following any specific set of rules / guidelines about how one should be doing things. That’s also not to say one can’t take advice and learn from others but it is never strict or applicable in all situations.As a toy example, in my old job, we had a rule that you should always put spaces around a binary operator. That often makes sense, but for example
3*x + 5*x*y + 7is arguably more readable than
3 * x + 5 * x * y + 7. Every seemingly good idea has an exception, usually loads of them. In most cases, it is best to simply trust the developers’ good judgement to do the right thing in the given circumstances.You do not believe that there is one right way to do something. That of course does not mean that some ways are not better than others in a given context.(Sorry for all the double negatives.)
- You have a certain passion for technology. There is a spark of joy in your eyes upon learning about a cool new technology, tool, trick or approach, upon finding a clever solution to a hard problem, etc.
- In general, you prefer bottom-up development and gradual evolution of software to big top-down design efforts. You prefer experimenting and trying stuff out to big theoretical discussions. But, as with anything else, you do not do this super dogmatically.
- You generally prefer simplicity and minimalism to large and complex systems and designs. You are broadly sympathetic toward (but not religious about) the Unix philosophy and the Zen of Python.
- Deleting 100 lines of code (without loss of functionality, e.g. after rewriting it in a better way) feels more satisfying to you than writing 100 lines of code.
- You consider enterprise and corporate to be curse words in a software development context. 😉
- You are a fan of Linux and open source software.
- You have made contributions to open source projects, even small ones, or have published projects of your own.
Your relationship to our mission
All of these are optional but definitely a plus:
- You are interested in, thinking about, or have worked on anything related to the topics we are interested in — forecasting, rationality, quantifying uncertainty, probabilistic / Bayesian thinking, epistemics, group decisionmaking, etc.
- You are a part of some of the wider forecasting / effective altruism / rationality / LessWrong / etc. communities
We can also offer hybrid product design / UX / education / software developer roles if you are interested in more than one of these aspects.
What can you expect: core principles of our team
- We believe that a programmer’s job should be, first and foremost, pleasant and fun. We try to remove annoyances standing in our way.
- We see programming as as much an art or craft as a science, as an essentially creative process, as expressed e.g. in Paul Graham’s famous essay Hackers and Painters. We give individual developers a lot of autonomy to use their best judgement when designing a piece of software, to choose the right tools for a given task, and to come up with creative solutions to problems. We hate micromanagement at least as much as you do (and frankly, we do not have the time for doing it ;-)).
- We do not believe in topdown design, i.e. trying to think up a detailed architecture for a piece of software before even writing a single line of code. We believe that pretty much nobody can get a design right on the first try, for several principal reasons:
- You realize a lot of requirements, problems and considerations only as you actually write the code.
- The human brain is very limited in how much information it can hold in working memory, process or consider together. And most complex software systems are far beyond this limit. Trying to think of the whole thing and all the possible considerations will just make your head hurt.We have seen developers get completely stuck trying to do this and then magically unstuck when convinced to let it go and just try something.
- When implementing a complex design, you usually spend a lot of time writing code before getting the first version that can be run. This
- Is frustrating to a lot of developers. For example, I enjoy writing code so much more when I actually see it do something, as compared to just writing thousands of lines with no end in sight.
- When making small incremental changes, it is much easier to catch and debug errors, as you can look for them in the small piece you have changed instead of a humungous pile of code you have written over several weeks.These points are well summarized in the essay Premature Design is the root of all evil.Instead, we suggest starting with the simplest version that does something, gradually improving it, gradually refining the design based on experience gained in previous steps. This is also nicely described in Hackers and Painters and compared to sketching done by painters.
- But of course we are also wary of the opposite extreme, of a piece of software becoming a tangled mess of historical artefacts, code duplication and spaghetti code. That is definitely not what we have in mind.
- Our answer to this dilemma is incremental design and a lot of (partial) rewrites.You start by writing the simplest, most concrete code possible, that just does something, without unnecessary generalization or abstraction. At the beginning, you do not care that much about code duplication or how it will with with the rest of the project. When it works, you add another little bit, e.g. to add or improve some functionality.As you write the code, you start to notice patterns. For example you realize that several separate pieces of code you have written share some common logic and can be rewritten in a more general way to remove code duplication. Or some part of the code has gotten too messy and hard to follow so it is a good time to rewrite that part in a more organized manner or perhaps add some abstraction to simplify it.But having written (or collaborated on, or at least read and talked about) the code has given you a very visceral sense for all the requirements, considerations and pitfalls and you are now in a much better position to come up with a good design than you were at the beginning.You usually go from simple, concrete and pragmatic things to more general, abstract and elegant designs as this need and opportunity arises and as you gain more experience with and insight into the structure of problem you are trying to solve and the solution space.
- But not too abstract. An important part of this approach is never adding more generality or layers of abstraction than is actually needed at a given point, e.g. with the noble goal of making future expansion easier or to address other hypothetical future needs.In our experience, this almost always backfires. It makes your current code unnecesarily complicated and harder to think about. And more often than not, future needs turn out to be different from what you expected anyway. People suck at predicting the future.We strive to solve only actual problems with code currently written or code we are just about to write, not hypothetical future problems of hypothetical future code. This is also called the YAGNI (You Ain’t Gonna Need It) principle.If extra needs arise in the future, you can just change the code (and in a much more targeted manner).An extreme case of over-abstraction is the pattern, common e.g. in the Java ecosystem, where there are so many layers of abstraction that more code is devoted to passing things around between the various layers than to actually doing something. This was beautifully described by Martin Mareš in a discussion about the philosophy of programming languages (Czech only) at the 1:01:58 mark.
- As with everything, this is just a broad guiding principle, not a strict dogma. Sometimes you see a good design for something from the very beginning. Great! Sometimes you have no idea. Then it is ok to not worry about it much and trust that you will figure it our later. Or someone else will.
How to apply
Short version: send an e-mail to email@example.com.
Long version: introduce yourself and let us know something about you. We do not need a formal CV (but you can include it if you have one lying around). We are interested in anyting that helps us understand (1) what you are capable of, (2) how you think, (3) what is your approach to software development. For example, you can talk about:
- Some cool projects that you worked on
- Personal and/or professional
- You can also include interesting non-software projects you have worked on
- If you worked on anything related to forecasting, rationality, or effective altruism, we definitely want to hear about it
- You can also include other achievements such as winning a competition of some kind
- That time you invented a really elegant design or solution, a cool workaround for a nasty bug, troubleshooted a really convoluted issue etc.
- Any thoughts you have about software development, programming languages, paradigms and tools, etc. For example:
- Any toughts in reaction to this document (including constructive criticism)
- What makes a programmer’s work pleasant and efficient?
- What are some of the most important lessons about software development you have learned?
- Which programming languages / tools / frameworks you (do not) like and why?
- … anything else on your mind
- Why you are interested in this position
- Whatever you think might be relevant
If you find this hard to write up, we can also schedule a call to talk about it.