DEV Community: Coder

A Hiring Manager’s Perspective on Tinkering & AI

Ben Potter — Wed, 08 Jul 2026 21:28:35 +0000

I'm a hiring manager on the product team at Coder, a growth-stage tech company founded in 2017. Everyone on the product team uses LLMs daily.

It's been fun to watch: docs folks fixing SEO issues on the website, engineers writing documentation, PMs building live prototypes, marketers shipping website changes directly. Nobody mandated any of this.

There are plenty of negatives too: layoffs, junior roles drying up, students worried about their careers, and a flood of low-quality generated content everywhere you look. I'm not going to solve those in this post. Instead, I'll share how AI actually affects hiring at one company that uses these tools heavily. If you're a candidate, I hope this helps you see how at least one company is thinking about it. I can assure you that we aren't alone.

Context on how we work

Every company values different things, so here's the environment my perspective comes from. If your values (or your company's) are different, your conclusions probably should be too.

We hire tinkerers. When I joined Coder, the first thing I did was stand up the product and poke at it. When I wrote my first blog post, I ended up also fixing the website's build process because it annoyed me. This attitude is company-wide. Nearly every department has built internal tools nobody asked for. We've also hired over 4 people directly from our user community, people who were already tinkering with the product before we ever paid them to. As we scale, we've had to get clearer about ownership, but I still want people who look outside their job description.

There's always more work than people. On the tactical side: improving our product's UX, writing a new feature or integration, improving documentation clarity, fixing a tiny bug. On the strategic side: better communication between departments, faster decisions.

We've seen a lot of hiring and firing. We're still a young company, but we've already been through plenty: we scaled too early once and paid for it with layoffs, and we've done hiring freezes while finding product/market fit. Right now we're hiring fast: 21 people in the last month, at a company of ~180. None of those layoffs or freezes had anything to do with AI. They came down to larger business reasons, the same boring ones that ended jobs long before LLMs existed.

What's actually changed

The number of open roles hasn't gone down. Expectations per role have gone up, but not in the way people assume. Myself and many of my peers are not concerned about squeezing more output out of everyone. It's about diversifying output in favor of impact: a docs person can contribute fixes directly, a PM can prototype their own ideas. This isn't about filling skill gaps. It's that going the extra mile got a lot cheaper, so we expect people to do it. We're less excited about "builders" in the raw sense, since building is cheaper than it's ever been. We're more excited about candidates who can demonstrate taste, understanding, and impact.

A good litmus test for me is whether someone is only using AI to generate new programs from scratch (likely to get scrapped/unmaintained), or to build on somebody else's ideas and understand a perspective or part of the company they haven't before. And then whether they actually get these shipped, improved, and retained. Getting 90% of the way there really doesn't matter

In practice:

We filter for taste. I want to understand if the candidate has a perspective, an experience, or even a distaste for something, and whether they feel comfortable expressing and applying it.
We still hire juniors (more than ever, actually). We just spun up a summer internship program, and we're hiring more junior roles than we ever have.
Communication skills are more important than ever. If someone sends you sloppy AI-generated work, or you disagree with an idea, you need to be willing to say so. And when you don't understand something, loop in a colleague to collaborate, without dumping work on them to review or shipping while hiding your gaps.

My environment is not for everyone

Coder values tinkerers, fast-paced ownership, and people going the extra mile. We expect a lot out of people, and those expectations aren't always documented in some playbook. Not everyone wants to work in an environment like that, and that's OK.

I'm also only in one specific department of Coder (product management and developer relations), and other teams and roles will be different. AI will certainly automate tasks that are central to some jobs. I'm not saying everyone will be fine, that all employees will become curious, or that those who prefer to get a task, execute, and repeat will (or should) succeed in a knowledge worker economy. I'm also not saying we have all the answers or that Coder is AGI-proof; I just don't think those conversations are useful when it comes to hiring or getting a job. What I am observing is a significant positive impact on how we work together and how we build better products, and I'm optimistic about the companies we can build with it.

If you're looking to get into another industry or work environment, I'd push you to research what that company values and how they write about AI (I'm sure they are). If you're a hiring manager, it can be helpful to write about your experiences like I did today. If nothing else, it'll help candidates figure out where they're a good fit and what types of work environments excite them as AI changes how we work.

If you're a candidate

More than any specific advice, I'd encourage you to think about how hiring managers are thinking (this blog post reflects how I think), rather than treating posts like this as a checklist.

That said, a few things transfer anywhere. Joining the community of a product you want to work on (ours or anyone's) is a great way to learn it and see what people are actually working on.

Form real opinions about the things you use and build, and get comfortable sharing those opinions, including when you disagree with someone or how you can make something better.

At this point, it isn't even about showing or hiding AI usage in an interview. I'd recommend spending more time thinking about how you can apply your unique skills to make the company better than showing off what you've built, unless what you've built has users and impact.

And if you're earlier in your career, don't count yourself out. As I mentioned, we're hiring more junior roles than ever, and I know we're not the only ones.

Faster JetBrains IDEs with shared indexes

Ben Potter — Sun, 02 Jan 2022 21:53:11 +0000

If you develop with IntelliJ IDEA, PyCharm, GoLand, or other JetBrains IDEs, it’s likely you’ve waited for “indexing” to complete after opening a project. While this may be annoying, it’s necessary for IntelliJ and other heavy-weight IDEs to have features such as code search, highlighting, refactoring, and code completion.

Waiting for an IDE to finish indexing a project might not be a big problem for many workflows. After the first load, indexes are cached and subsequent runs are faster. However, indexing time can be a huge blocker for developers, especially in these cases:

large projects (monorepos, many dependencies, monolithic applications)
running old/slow machines (indexing is CPU-intensive)
ephemeral developer workspaces (containers, remote IDEs)

In this post, we’ll cover how shared indexes can significantly reduce IDE load times, share some examples, and a one-line command to generate these for your project. (Historically, shared indexes have been difficult to set up)

First, how indexing works

Indexing works by traversing the project’s codebase to create a “virtual map” of classes, methods, and objects for future lookups. After the index is generated, it is cached on your device for later use.

Indexing a codebase will likely take the longest the first time you open it on your machine. When the codebase changes, such as pulling code or switching branches, your indexes will “update,” but significantly faster than the first time.

Shared indexes ⚡

Shared indexes make it possible to host pre-generated indexes for others to download, significantly improving loading speeds across your team. These remote indexes work in conjunction with local indexing to ensure your IDE always has up-to-date information on the codebase.

GIF: Loading the code-server project in WebStorm

Generating shared indexes for your project

JetBrains has a guide for creating shared indexes, but it involves many steps, including downloading custom tooling and uploading indexes to a CDN. It also lacks instructions for automating this process, to generate indexes in CI, for example.

Using a Docker container to generate shared indexes makes it simple to try locally or automate with cron/CI:

cd your_large_codebase/

# generate shared indexes
docker run -it --rm \
  -v "$(pwd)":/var/project \
  -v "$HOME"/indexes-output:/shared-index \
  -e INDEXES_CDN_URL=https://cdn.myserver.com/project \
    -u "$(id -u):$(id -g)" \
  bencdr/indexer:idea-2021.3

After generating indexes, you can upload the output folder to your CDN, or a local server. You can also use shared indexes without a CDN by using a network share or even your local filesystem for testing. Check out my GitHub repo for details:

bpmct / jetbrains-indexer

Generate & package JetBrains shared indexes with a Docker container.

Benchmarking shared indexes

I tested indexing time for some popular projects on my 2019 MacBook Pro. To benchmark your own projects, File → Invalidate Caches in your IDE will allow you to opt in/out of downloading shared indexes to simulate first launching your project.

Project	Language(s)	Local indexing 🐌	With shared indexes ⚡	Improvement %
kubernetes/kubernetes	Go	2m 40s	22s	727%
cdr/code-server	Typescript	2m 30s	34s	441%
Coder internal monorepo	Go & Typescript	3m 20s	32s	625%
jetbrains/intellij-community	Java	6m 30s	2m 15s	288%

These times were averaged across two test runs. Your mileage will vary depending on network speeds, device performance, etc.

Remote development & shared indexes

Recently, JetBrains released remote development support, making it simple to develop from powerful, remote workspaces. On-demand workspaces have a lot of benefits, such as faster onboarding and better reproducibility. However, first-time indexing happens much more frequently, since, after all, workspaces are meant to be ephemeral.

Shared indexes work with Coder, our remote development platform. Coder supports all JetBrains IDEs locally, or via the web browser. If you don’t want to host a CDN for shared indexes, you can include them in the workspace image, so everything loads in a snap ⚡

If you’d like to learn more about Coder, you can request a demo or try it for free.

References

I developed on an iPad for two weeks: Here’s what I learned

Joe Previte (he/him) — Mon, 08 Feb 2021 21:24:31 +0000

“We’re going to send this to Apple and you should get it back in 5-7 business days.”

And this is how the first work week of 2021 started for me — my brand new MacBook Pro keyboard unusable and out of my possession for what could be two weeks. Fortunately, my coworker had sent me an iPad testing device a few days prior. The timing couldn’t have been better.

I made a decision.

I insisted to my manager and HR that I could use the iPad while I waited for my laptop to be repaired instead of letting them send me a new laptop. Plus, it gave me an excuse to answer the question, “Could I work and develop full-time off an iPad?”

Here’s what I learned.

You can use an External Monitor, Keyboard, and Mouse

My home office setup includes:

At first I thought I couldn’t use these with the iPad. After some trial and error, it turns out you can! I connected the keyboard via USB to the monitor and then the monitor via USB-C to the iPad and it “just works.” The mouse was easy to connect via bluetooth.

The iPad mirrors the display to the monitor, which means you don’t get the screen real estate you do with a laptop, but it’s better than nothing. There were also some apps which would not mirror to the external monitor — most notably the HEY email app and the GitHub app.

VS Code on iPad feels like magic

I still can’t believe you can use VS Code on an iPad. Using Coder, I created an environment for me to work on code-server. I was then able to install the editor (code-server) as a PWA and use VS Code as if it were a native app on iOS. The experience is magical. You feel powerful, like you can take your editor anywhere you’d like. And thanks to the Dev URLs, I can run apps on any port, and create a Dev URL to access them from the browser. This made my life a lot easier.

iPads as Devices are Portable and Powerful

The battery of the iPad surprised me. It felt like it lasted way longer than I would have expected. The performance felt fast. There was hardly ever any lag. With the Magic Keyboard, I felt like I could take the iPad anywhere and start coding. It was liberating. In addition, I loved having the cmd + shift + 4 shortcut for taking screenshots and the built-in screen recording added in iOS 14.

Didn’t have much use for Apple Pencil

Along with the Magic Keyboard, I had the Apple Pencil at my disposal with my iPad. Unfortunately, I didn’t find much use for it. I am not blaming Apple or the iPad for that, but rather myself. I think if I were more of a designer, there would be use. Or if I were a student in college taking notes, I could use it. I didn’t have much use for it and can’t say I recommend it to fellow developers considering a full-time iPad setup.

Browsers are Inconsistent

Sadly, one of my main frustrations was the lack of consistency for browsers on iOS. My preferred browser is Firefox. However, there were a number of bugs which caused me to switch over to Chrome. The keyboard shortcuts I was used to from desktop did not always map over to the iOS apps, which slowed down my workflow significantly. There are also a number of UX-related issues for mobile apps. Chrome wasn’t perfect, but it was better than Safari in most aspects. My one wish: make a browser that is consistent across platforms and stable.

Use the PWA and Gain Control Over Keyboard Shortcuts

If you’re going to work off an iPad and write code, being able to download your editor either as a native app or a PWA is a must. This is the only way for you to get keyboard shortcuts that don’t conflict with global or app shortcuts.

Once I started using the PWA for Coder’s editor, my workflow levels approached normalcy. I had to manually add a lot of keyboard shortcuts to my settings in VS Code/code-server. Once I did, I felt like I was back in my usual flow.

Inspect Browser is a Tool You Need

When you’re developing on iPad and using the standard iOS browser apps (Chrome, Safari, Firefox), you don’t have access to the developer tools. This means you need a workaround. The best one I found was an app for purchase ($6.99) called Inspect Browser. Although the UX isn’t that of your standard browser devtools, it succeeds in filling the gap. It provides you with the ability to look at the console and inspect elements. There are more features but those were the two it helped me with the most.

Summary

Overall, I really enjoyed the two weeks I spent developing off an iPad full-time. There were many moments I wanted to give up and ask HR to send me a laptop, but I’m glad I stuck with it. I have a greater understanding of the iPad workflow from a developer perspective and I hope I can translate that into product improvements that make the UX for both Coder and code-server users even better.

Thanks for reading! It would mean a lot to me if you shared this on Twitter. If you have questions or want to get in touch, feel free to shoot me a DM on Twitter.

This article was first published on the Coder blog here.