Frequently asked questions about work at CobbleWeb

Find quick answers to the most commonly asked questions about our project flow, tech stack, approach to innovation, work culture, and more. If you can’t find it here you are welcome to shoot us an email at: recruitment@cobbleweb.co.uk

Jump to the appropriate section:

• Tech Stack
• Innovation
• Project management
• Collaboration
• Product Discovery
• Remote Work Culture
• Recruitment process

Tech Stack

Who decides which tech stack will be used in a new project? What process is followed to select a tech stack?

Tech stack evaluation is done by the Tech Lead or a senior engineer nominated by the TL. The starting point is usually previously epics or projects that incorporated similar features or functionality. If brand-new functionality is required to support a particular business goal, a senior engineer is nominated to investigate and evaluate the most suitable technology.

The TL or nominated senior engineer will produce a technical specifications document which is presented in a demo followed by a Q&A session. Specifications are interrogated by the whole team until validation. The Product Manager, for example, will look at the tech stack’s alignment with the proposed business solution (e.g. revenue model). Note that this process is followed for each epic.

Also see FAQ: How are technical requirements managed?

Why do you say you are tech agnostic if the tech stack is defined in the job description?

Marketplace projects often utilise the same features. In that case we will use a proven tech stack. However, this is always subject to whichever technology best serves the project’s business goals. 

Reasons for utilising different technology may include: better support for a unique functionality, greater speed of implementation, cost-effectiveness, the client insists on it, or new technology that significantly improves on existing technology.

Learn more about how and when we evaluate new technology

Why do you have two tech stacks (PHP/Symfony and Node.JS/NestJS)?

We have both JS and PHP teams due to client preference or ongoing projects where the original platform was built with PHP.

Learn more about our tech stack

Innovation

What is CobbleWeb’s approach to AI tools?

Our engineers already use AI tools for automated code generation, testing, and debugging (Copilot).

Do your projects include AI features or functionality?

We’ve used AI in a variety of features such as customer support, transaction reconciliation, and data pipelines. We are also looking at using AI in the automation of certain product functionalities. 

What is ShareWise?

JavaScript library of modular components that can be combined in a plug-and-play fashion to build online marketplaces. It covers all the most common marketplace features, such as user -, order-, product- and store management, shipping, payment processing, etc. 

What are ShareWise’s benefits for engineers?

Its component-base architecture offers many benefits: much faster rollouts, flexibility, parallel workstreams, and easier maintenance and updates. Even more important, the quality of ShareWise architecture has been proven in real-world scenarios. Every component has been stress – and performance tested in high-growth marketplace platforms like FanPass and Nestify.

Learn more about innovation at CobbleWeb

Project management

What are the next steps between the user journey mapping and the MVP? 

CobbleWeb projects are broken down into the following phases:

1. Grooming: interrogate the business case, compile a list of user journeys, align initial epics with the business model.
2. Design: user flows and UI mockups created in Figma, interrogated in an Internal Design Demo, signed off in a Client Design Demo.
3. Functional specifications: use cases for each epic, UI interactions, mapped-out revenue model.
4. Technical specifications: database schema, API endpoint list, tech stack/architecture, libraries, integration flow
5. Development
6. Internal demo
7. Client demo
8. MVP launch

Are usability tests done on the UI built for the MVP?

It depends on the type of event and if the client has sufficient users to justify user testing. In general, we monitor and analyse user behaviour with analytics tools like Heap, Hotjar, and Snowplow. This forms part of our iterative development process.

How long does it take to build a marketplace MVP?

The short answer (and a gross generalisation): three to nine months. 

Variables that impact the development timeline include: 

• The stage of the marketplace project (are we building from scratch or improving an existing platform?), 
• Feature selection (which features have been prioritised in the first version?), 
• Client budget (how many resources have been allocated per month?), 
• Duration of the discovery process (more complex marketplaces obviously necessitate more detailed discovery)

Who is responsible for project documentation?

The product manager is responsible for the initial product roadmap with a list of epics. This is followed by a storyboard that breaks down epics into individual user stories. The product manager also documents the functional specifications based on feedback and contributions from team members.

Generally, a senior engineer is nominated to lead an epic and write its technical specifications. This will include the tech stack, any tools we are going to use, and the way we are going to develop the feature. It also covers database models, API endpoints, and service or business layer changes. The owner of the epic also prepares the internal demo document, which should include demo scope, feedback and agreed-on actions.

Who is responsible for testing? 

Our philosophy is that quality is the responsibility of everyone involved in the development process. That’s why we have guidelines, including functional specifications, in place for each task and involve clients closely in the testing process.

• Development phase: 
  • Individual code quality check (including use of AI tools), code reviews by senior engineers. 
  • Our definition of done for tickets includes three steps: (1) engineers test every ticket locally and on the UAT server when possible, (2) tickets are then assigned to the QA, (3) when pushing code breaks something or impacts other engineers’ work it is immediately discussed.
  • Our fronted expectations are equally rigorous. When we present a demo to the client we want them to get exactly what the designer showcased. It’s the engineer’s job to make sure that each page matches the original design. 
• Internal demos: need to be user-centric, collaborative, well-prepared, and succinct
• Client demos: typically done at the end of an epic to demonstrate a full feature or a component thereof. As part of our commitment to continuous improvement all demos are documented and reviewed. Participants each list what they thought were done well and what can be improved on.
• Testing by client: UAT environment with automated feedback mechanisms powered by tools like Bugherd and Usersnap.

How is testing done?

We follow a Test Driven Development (TDD) approach as part of continuous integration and continuous delivery (CI/CD). This includes the following aspects:

• Defining specific, measurable, and testable acceptance criteria
• Creating automated test cases based on the specifications
• Calculating the coverage of automated tests

Testing and monitoring include:

• Integration tests
• Unit tests
• Technical health
• Database audits
• Load testing
• Feature flags (aka toggle or switch)
• Regression testing
• Coverage rates
  

Some of the QA tools we use:

• Git pre-commit hooks
• Gitlab actions
• Code quality checks: ESLint | CodeRabbit | PHP CodeSniffer
• CI server: Jenkins
• APM tools like Datadog and Sentry
• AWS monitoring: Cloudwatch
• Test automation tools: Cypress | Jest | Nightwatch
• Test management tools: Xray | Zephyr
  

How often do we deploy code to production?

Often (even daily) in the case of Kanban tickets. Larger releases that form part of epics are deployed  a few times per month.

Each engineer should spend 10 out of 20 work days per month on building tickets. The balance is usually taken up by project management, specification, demos, etc. This translates into shipping at least one epic per month so that we can help our clients test the market quicker and more often.

How are tasks or tickets assigned? Who is responsible for deciding which team member works on what?

The Tech Lead assigns an engineer to lead each epic based on experience and areas of interest. This engineer, with support and validation from the rest of the team, is responsible for identifying the best solution for that epic. 

The epic leader then creates tickets based on the technical requirements. Once the tickets have been estimated, prioritised, and allocated development can commence.

How do you measure engineers’ performance?

There is a clear process to evaluate each team member’s work, which rests on three pillars:

• Quality of delivery – Was there a successful demo with no bugs? What is the UAT ratio? How much is spent in fixing bugs vs building? Is the client happy?

• Predictability – How accurate was the ticket estimation? We work with a 15% leeway, but a good discovery will always help you in this regard.

• Teamwork (collaboration effort) – How much value did the team member’s input add to shaping optimal solutions? How available was the team member to assist the rest of the team?

Collaboration

How many standard meetings do we have per day/week/month?

• Weekly: Grooming meetings
• Every two weeks (Wed): Sprint planning
• Every two weeks (Tue): Review & Retrospective

How does collaboration happen outside meetings? 

We usually communicate via Mattermost, Jira for ticket specific discussions, and Gitlab for discussions around code. Communication with clients is done via Jira support tickets and email.

What happens when someone has an urgent question?

We rely on our Mattermost channels in such instances. You can either @ someone directly if the issue concerns that individual specifically or you can direct your query to the channel or here to get an answer from everyone.

How do we help someone who is struggling?

If it is a technical issue whoever is available will try to mentor or provide reference documentation. We can also use screensharing and peer programming. If it’s a productivity issue, we try to redistribute the workload. Sometimes that entails adjusting the work environment such as simplifying processes or choosing different tools.

How often do engineers engage or communicate with clients?

Support interaction usually occurs when a client is notified of an engineer’s comment on a ticket. The client may then respond in kind to clarify or query.

Although rare, engineers with special insights or skills may attend client meetings or even present a proof of concept.

Senior engineers usually collaborate with clients during the last mile before going live. We often have to confirm budgets, preferences or strategies with the client. Dealing with them directly streamlines the process and avoids delays.

What is the level of collaboration outside the immediate squad – e.g. with the product manager, designer, QA, etc?

At CobbleWeb, engineers’ inputs on design and functional specifications are valued. Especially during the discovery phase, engineers will review the design and might request changes.They are also at liberty to ask the Product Manager for validation or clarification of functional specifications.

Which steps of the design process are engineers involved in?

The PM discusses the scope of the epic with the client to clarify the functional requirements of each feature(s). Our design team uses those requirements to create a draft design.

The engineering team then reviews the design by dropping comments on the Figma file. They consider the following aspects: suggestions to improve the UI/UX, feasibility issues (removing or revising functionality), delivery speed (should some functionality be descoped?), and clarification of missing elements.

How are technical requirements managed?

Generally, a senior developer is nominated to lead an epic and write its technical specifications. This will include the tech stack, any tools we are going to use, and the way we are going to develop the feature. It also covers:  integration flows, libraries, database models, API endpoints, and service or business layer changes.

Once the first version is completed, the epic leader will organise a meeting to discuss them. Revisions are made based on feedback which are usually reviewed and approved asynchronously by the rest of the team. 

The epic leader then creates tickets based on the technical requirements. Once the tickets have been estimated, prioritised, and allocated development can commence.

How are internal demos organised?

When development is completed for an epic, the owner(s) of the epic present an internal demo to the team. Any bugs or areas for improvement are added to a notes section on the internal demo document. 

This is followed by a retrospective where we discuss individual feedback on what worked and what can be improved. Agreed on actions are added to the document.

Learn more about collaboration at CobbleWeb

Product Discovery

How does product discovery work at CobbleWeb?

During discovery we identify and validate the problems that need solving, the markets that are targeted, and the solutions that are offered. On a practical level, it means gaining an in-depth understanding of user personas, user flows, and business parameters. 

Our goal is to provide the client with:

• A list of first version epics
• The tech stack required to build those epics
• Resource requirements

Key steps in our discovery process:

1. Interrogation – deliveries include a grooming brief and data evaluation (existing platforms) compiled by PM  in conjunction with client.
2. Design – deliveries include a list of user flows, design elements, mockups created by designers with input from product manager and lead engineer.
3. Documentation – deliveries include a storyboard (PM with TL support), functional specifications (PM with TL support and team feedback), and technical requirements (TL in conjunction with team)

Learn more about our discovery process

Remote Work Culture

Since when do you work remotely?

Remote-first has been baked into our culture from the very beginning, since we were founded as a distributed company in 2012.

What are your hiring zones? Can I work from anywhere?

We prefer that team members are located in time zones between GMT and GMT+4. You can work from up to three (3) pre-approved locations, as long as you have a professional work environment and a fast internet connection. For example, your home, the home of a relative you visit often, or a co-working space.

What are your working hours? Do you have core hours?

Although most roles are full-time, we do offer flexibility in the form of core hours (per team), when team members need to be available, combined with flexible hours, which are scheduled by individual team members.

We don’t have company-wide core hours, but we do expect team members to share at least five hours per day. This should happen naturally if you are based between GMT and GMT+4. 

What devices are used for remote work?

Our team members use a Mac Mini. This requires a properly setup work environment, including a desk and at least one external monitor.

Do we have an on-call policy?

We do not have a default on-call policy. Support outside of normal business hours is usually rendered in terms of an additional service contract. Team members who are willing and available are accordingly renumerated at a higher rate. In addition we follow pre-emptive strategies to minimise issues outside of normal business hours. For example, we don’t release new versions on Fridays.

Learn more about our remote work culture

Recruitment process

What are the steps in your recruitment process?

1. Initial screening call

• Professional motivators
• Current or recent projects, as well as other relevant projects
• Scope and impact of contributions and achievements
• Basic technical and theoretical background
• Salary expectations

2. Product interview

An in-depth conversation about your relevant project experience:

• Gauges your analytical thinking, problem-solving abilities, and sense of purpose.
• Topics include the nature of your contributions, challenges faced, and decisions made.
• Conducted by a product manager and a senior engineer.

3. Technical interview

Technical discussion and live coding exercises around the following topics:

• Systems design
• Relevant frameworks (E.g. Nest.JS, React, Symfony)
• Conducted by a tech lead and a senior engineer.

4. Final interview

Also known as the CEO interview, this fairly unstructured conversation allows us to get to know each other better and evaluate if there’s a good cultural fit between us. 

More details about each recruitment step