Full-Stack Software Engineer, experienced

• Working with a modern tech stack built on AWS with Python, Node.js, Terraform, Docker and Typescript
• Building new front-end and back-end features, working with UX designers to create delightful and highly-performant products
• Instilling best practices into the development process, including automated testing, code organization and style, and application architecture within an agile environment
• Evaluating potential new technologies
• Writing code that builds new companies and products

• A full-stack generalist with 2+ years experience building applications
• Proven ability in writing clean, scalable code with significant experience in one or more programming languages
• Solid knowledge of programming fundamentals - algorithms, data structures, design patterns, and paradigms
• Excited to move fast and know how to prioritize and make critical decisions
• Comfortable with and curious about working outside of a traditional narrow engineering role
• A self-starter: you have started something on your own before -- an open-source project, a new project within a company, a start-up, or something else
• Can effectively communicate software engineering issues to business professionals, and business issues to software engineers
  
  

• Proven capability in creating a successful software product; owning/implementing key decisions on features, architecture, scaling, and profitability. Particularly in AI or solving a novel problem
• Experience planning and executing work modules that span several months
• Broad skillset that blurs the lines between software engineering and data science
• Exceptional computational background (e.g, significant contribution to libraries/modules and/or has a relevant PhD)
• Exceptional business background (e.g., managing client relationships and scoping projects while leading an engineering team, and/or MBA from a leading program)

• Very strong CS, math, physics or similar degree from a leading program. PhD and MBA applicants actively considered 

The Foundry Interview Process

Foundry interviews share some common features with other companies hiring Software Engineers and Data Scientists, and have some important differences. These differences are a reflection of the roles our employees play, which are focussed on the early stage development of companies where idea generation, product-market fit and partner interaction may be significant aspects of their jobs.

All our roles have technical interviews that look for core competencies in the day-to-day tools of Software Engineering, and the ability to discuss technical work, formalize generic problems into a quantitative system, problem solve, and act as part of a team. Many of our interviewees will recognise these as common topics for Data Scientist and Software Engineering roles, although they may find that we ask somewhat more open-ended questions, care more about collaboration, or draw on a mixed pool of skills.

We also ask case-study type interview questions, which are less usual for technical roles. For those who have not heard of these interviews, case studies are open-ended business problems that do not have set answers. They typically require the interviewee to think through the provided information and the context of the problem, decide what is most important, and then build a structure to answer the most important part of the problem (asking the interviewer for further information where appropriate).

We ask case studies because Foundry is solving problems that haven't been solved before, and these problems require business-orientated problem-solving and the ability to prioritize in a world of uncertain information and constrained practical actions. Finding a strategic niche and writing the software that realizes value from it is the heart of how Foundry builds new AI-driven SaaS businesses.

We at Foundry are therefore looking for people who are different, and do not fit into any common mold in technical or business careers (although generalists are frequently star performers in these roles). Our staff will often describe this as not only wanting to write code to solve a problem but also being able to define the problem that we are solving.