DEV Community: Alik Khilazhev

Forward SMS to Telegram with Android

Alik Khilazhev — Sun, 12 Jul 2026 14:32:54 +0000

A few years ago, I wrote a post on how I automated SMS forwarding using second-hand 3G modems and a Gammu SMS daemon running on a Linux server.

This setup worked well for a while, but then became outdated due to the instability of USB dongles and the planned deprecation of 2G and 3G networks in Europe.

One day, I got tired of replugging USB modems and manually restarting containers, so I decided to look for a new solution.

First, I thought I would build my own device using existing 4G modules for an ESP32 or a Raspberry Pi, but I quickly discovered it would cost me a fortune to support two or more SIM cards.

Then I looked for off-the-shelf solutions. I found some cool 8/16/32+ SIM support boxes from Chinese vendors. But again, they were pricey, and I didn’t need so many SIM cards.

After that letdown, I returned to the old, forgotten idea of using a dedicated Android device for my task.

Device

I didn’t have a spare Android device at home, so I looked for a second-hand working one with two SIM slots on Wallapop.

I ended up buying a Moto E14 for €25.

I tried to root it as soon as I received it, mostly out of curiosity and to gain better control over my device. But I was unable to find a working solution for that.

So I gave up and tried to configure everything without root access.

Spoiler: I succeeded. No root was needed.

Software

I had two SIM cards, and the current setup forwarded SMS messages to different Telegram channels.

I looked for an app that would allow me to do so. I considered the telegram-sms app, but after a quick look, it seemed not to support splitting SMS messages into separate chats.

In the end, I chose to go with an android_income_sms_gateway_webhook. It does not support Telegram specifically, but it lets you configure a webhook that can call any service, including Telegram.

However, to split SMS messages from different SIM cards into separate channels, I needed to implement a webhook handler, which took Codex about five minutes.

Here is a link to the GitHub repository: github.com/alikhil/sms-forwarder-telegram-webhook

It is a simple, stupid Python web server that parses the JSON and sends two JSON requests to Telegram servers for the right channel.

I deployed the webhook handler in my homelab using Docker Compose, and it became the bridge between the Android app and Telegram:

services:
  sms-webhook:
    build: https://github.com/alikhil/sms-forwarder-telegram-webhook.git#main
    restart: always
    environment:
      DEFAULT_TARGET_CHAT_ID: -88005553535
      SIM1_TARGET_CHAT_ID: -100500
      SIM2_TARGET_CHAT_ID: -100500800
    env_file:
      - .env # includes TELEGRAM_BOT_TOKEN
    ports:
      - "8000:8000"

I configured the app to send SMS messages:

That’s it. The SMS forwarding path was working end-to-end.

Monitoring

After the pain of previous solutions, I wanted to be notified if something failed.

If I did not receive an SMS that I was expecting, I would not know that I had missed it. The app might crash, or the battery might run low.

Fortunately, the SMS gateway app supports sending heartbeats.

I set up a Uptime Kuma monitor and configured the app to send heartbeats every 5 minutes. Kuma expects a heartbeat every 5 hours.

The values were tuned empirically because the app does not strictly follow the schedule. As I understand it, this is a technical limitation of the app running in the background.

But it is okay for me, even if I learn about a failure after twice the normal interval.

Power management

I didn’t want my Android device connected to a power supply all the time because I believed the battery health would suffer as a result.

Also, I didn’t want to connect and disconnect it manually every time. I’m an engineer, after all. It must be automated.

I wanted it to work like this:

If the battery level is below 20%, connect the power.
If the battery level is above 90%, disconnect the power.

I had a spare smart and controllable Shelly Plug that I could use for such automation.

I could probably use one of the Home Assistant plugins to implement it, but I don’t use Home Assistant and didn’t want to install it just for this small use case. That would be overkill.

The next step was to find Android apps that could send a webhook when the battery reached a certain level.

There were surprisingly few decent apps for this. It seems like a very niche use case.

The only thing I found was Android Remote Notify. And, of course, I couldn’t configure Shelly automation directly there.

So, Codex handled another simple webhook handler that calls the Shelly Plug API when the battery reaches a certain level.

services:
  battery-webhook:
    build: https://github.com/alikhil/android-remote-notify-webhook-handler.git#main
    restart: always
    environment:
      SHELLY_PLUG_URL: http://192.168.99.88 # Your shelly plug IP
      PORT: 8080
      LOW_BATTERY_THRESHOLD: 20
      HIGH_BATTERY_THRESHOLD: 90
    ports:
    - 8080

Only after I had configured and deployed everything did I realize the app had a major limitation: it did not have a way to trigger an alert when the battery level exceeded 90%. It only supported a lower-bound threshold.

I didn’t want to search for another solution when I was so close to completing the current one. Luckily for me, the app was open source.

I concluded that a simpler approach would be to send battery level periodically, and the webhook handler controlled the plug based on those reports.

I prompted Codex in the repository to develop the new feature.

After 15 minutes of hacking, it produced a solution. I didn’t have a full Android development setup, and I didn’t want to bloat my Mac with it.

So I asked Codex to build the APK inside Docker. Five more minutes and it was done.

I replaced the app with the custom patched build, and it worked.

I went ahead and created a pull request to upstream, and it was accepted. As a nice bonus, I no longer need to maintain a fork.

To be fair, heartbeats and battery-level webhooks were not coming on a strict schedule.

To monitor the webhook handler, I built a page that reports things like:

When the last state was reported
What the battery level was at that time
The last command sent to Shelly.
Etc.

Caveats

During webhook testing, I encountered an issue where both Android apps struggled to send requests to an insecure HTTP endpoint.

There is probably a configuration option somewhere that allows such behavior.

I simply routed the traffic through my custom domain with Let’s Encrypt certificates.

Final thoughts

It was my first time tinkering with Android, and I enjoyed it. I expected it to require more hassle.

Happy hacking!

How to Quickly Prepare for Software Engineering Interviews

Alik Khilazhev — Thu, 23 Apr 2026 22:40:38 +0000

A few months ago, I found myself needing to prepare for a series of job interviews within a very limited timeframe. It was a stressful experience, but it ultimately worked out well. I decided to share my notes and reflections in case they’re helpful to others in a similar situation.

This is especially relevant if you’re not actively job hunting and suddenly receive an interview invitation, leaving you with limited time to prepare but a strong desire to maximize your chances of success.

Disclaimer: The tips described in this post may be more useful for senior engineers with hands-on experience and engineering intuition.

HR Interview

The internet is full of articles listing all possible HR interview questions. I recommend spending a bit of time on them just to understand what to expect and not be surprised.

However, in my humble opinion, there are two main points to focus on during HR interview preparation.

First, you need a short story that tells your experience briefly. Avoid listing every bullet point from your CV. Instead, focus on highlighting your key achievements. Also, your story must be aligned with the position you are applying to. Yes, you might need to adjust your story for different jobs at different companies.

Second, it’s important to have a clear motivation. Why do you want to change your job, and why this company/role? What kind of job are you looking for?

System Design

If you have some experience doing System Design interviews or have never done it, start by learning the Delivery framework. Understand each section.

Watch at least one video on how it’s done. The more, the better. These videos from Hello Interview channel are really good, though.

If you are applying to a FAANG company, you may search for leaked system design questions from that company and spend some time preparing for them. But there is no guarantee that you will get the same topic, thus I would not recommend spending all your time here.

If you can, do a mock interview. Ask a friend or find someone to practice with.
If you can’t, then try to walk through alone, but talk through everything out loud.

During the interview, treat the interviewer as a colleague, ask questions, ensure you understand the problem, and that you have not missed any important requirements before building the design of the system.

Don’t rush.

Live coding

This part is really tricky. If the company tends to use LeetCode-style interviews, there is no shortcut here. You need to solve hundreds of them to really feel confident. You may need to refresh your memory on algorithms you feel less confident about (for example, I always forget about corner cases for binary search).

Again, if it’s a big / well-known company, you can try to search for leaked coding interview questions.

Behavioral interview

S.T.A.R (situation task action result) & C.A.R.L (context action result learning)

There are dozens of questions you could be asked in behavioral interviews. And you’re expected to structure your answers using the STAR framework. This means you need to tell a story by defining a context, your actions, and results. You could go and just prepare a STAR format answer to all such questions, but it will take a lot of time, and it’s suboptimal. This, combined with the fact that the same stories can be used for different questions, makes the situation easier for you. You can prepare 7–10 stories that will cover most of the questions. During preparation, you can write them as text, but don’t read them during the interview. It tends to sound unnatural.

When telling your story using the STAR method, make sure your final sentence clearly highlights a positive outcome. Adjust your tone to emphasize this closing part so it stands out.

The STAR framework is a standard. But also check CARL in some questions, it would be good to tell what you have learned from that story.

Here are some materials that helped me to prepare for a behavioral interview:

Hello Interview - Behavioral Interview Discussion with Ex-Meta Hiring Committee Member- must watch Behavioral interview, although I would recommend watching it even before the HR interview, because it gives a bunch of helpful tips about self-presentation
https://thebehavioral.substack.com/ - Strategies, tips, and resources to prepare for your next behavioral interview from a FAANG+ insider.

Project Walkthrough

Some companies have such an interview stage. It’s quite unpopular but still exists.
You’re asked to present a project or problem you worked on. You explain the context, problem, solution, results, and your role in this story. It’s like showing the result of your work to colleagues from different departments/teams.

This stage is very open-ended. You are not given specific instructions, and there is not much information on the internet with recommendations on how to prepare and conduct such interviews.
When I found out I would have this interview, I was initially shocked and unsure how to prepare, as I didn’t know what to expect. It wasn't until I realized that in reality, it’s you, the interviewee, who rules this interview. You choose the project, decide what to include and omit, control the level of detail, and you are coming up with the story you know, with all the answers for all possible questions, because it’s your story.

So, make the most of this stage. Prepare your story, make a few slides / notes / architecture sketches.

Don’t dig into details too much. Leave a space for the questions.

And even if there is no dedicated interview, you may be asked to tell in detail about a certain problem/project you were working on. So, be prepared. Have your story!

Final thoughts

When answering open-ended questions, aim to tell stories where the scale of the problem matches the level of the role you’re applying for. For example, if you are asked, “Tell me about a challenging/interesting problem/task you were working on recently.” Optimizing an SQL query by adding an index may be fine for junior roles, but it won’t carry enough weight for senior positions. Interviewers would expect to hear something bigger, challenging, higher stakes, and often involving cross-team collaboration, such as migrating a large system to Kubernetes.

Question back. You should ask questions to learn more about the company, their culture, the hiring manager’s management style, and what they like or dislike about their work. Prepare a list of questions before the interview.

Start preparing in advance. Even if you’re not planning to change jobs anytime soon, you can begin investing in your future by:

solving one LeetCode problem a day
keeping track of tasks/projects you’ve completed, along with your achievements (many companies require this anyway for performance reviews) – this would be a foundation for your stories in behavioral and project walkthrough interviews.
keeping your CV and LinkedIn up to date.

Kubernetes In-Place Pod Resize

Alik Khilazhev — Mon, 29 Dec 2025 09:00:00 +0000

About six years ago, while operating a large Java-based platform in Kubernetes, I noticed a recurring problem: our services required significantly higher CPU and memory during application startup. Heavy use of Spring Beans and AutoConfiguration forced us to set inflated resource requests and limits just to survive bootstrap, even though those resources were mostly unused afterwards.

This workaround never felt right. As an engineer, I wanted a solution that reflected the actual lifecycle of an application rather than its worst moment.

I opened an issue in the Kubernetes repository describing the problem and proposing an approach to adjust pod resources dynamically without restarts. The issue received little discussion but quietly accumulated interest over time (13 👍 emoji reaction). Every few months, an automation bot attempted to mark it as stale, and every time, I removed the label. This went on for nearly six years...

Until the release of Kubernetes 1.35 where In-Place Pod Resize feature was marked as stable.

What In-Place Pod Resize Brings

In-Place Pod Resize allows Kubernetes to update CPU and memory requests and limits without restarting pods, whenever it is safe to do so. This significantly reduces unnecessary restarts caused by resource changes, leading to fewer disruptions and more reliable workloads.

For applications whose resource needs evolve over time, especially after startup, this feature provides a long-missing building block.

Impact on VerticalPodAutoscaler

The new resizePolicy field is configured at the pod spec level. While it is technically possible to change pod resources manually, doing so does not scale. In practice, this feature should be driven by a workload controller.

At the moment, the only controller that supports in-place pod resize is the Vertical Pod Autoscaler (VPA).

There are two enhancement proposals enable this behavior:

AEP-4016: Support for in place updates in VPA which introduces InPlaceOrRecreate update mode
AEP-7862: CPU Startup Boost which is about temporarily boosting pod by giving more cpu during pod startup. This is conceptually similar to the approach proposed in my original issue.

Here is an example of Deployment and VPA using both AEP features:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example
spec:
  replicas: 1
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
        - name: app
          image: my-heavy-java-app:stable
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 1000m
              memory: 1024Mi
            limits:
              cpu: 2000m
              memory: 2048Mi

---

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  resourcePolicy:
    containerPolicies:
      - containerName: "app"
        minAllowed:
          cpu: "250m"
          memory: "512Mi"
        maxAllowed:
          cpu: "3000m"
          memory: "8192Mi"
        # The CPU boosted resources can go beyond maxAllowed.
        startupBoost:
          cpu:
            type: "Factor"
            quantity: "2"

With such configuration pod will have doubled cpu requests and limits during startup. During the boost period no resizing will happen.

Once the pod reaches the Ready state, the VPA controller scales CPU down to the currently recommended value.

After that, VPA continues operating normally, with the key difference that resource updates are applied in place whenever possible.

Limitations

Does this feature fully solve the problem described above? Only partially.

First, most application runtimes still impose fundamental constraints. Java and Python runtimes do not currently support resizing memory limits without a restart. This limitation exists outside of Kubernetes itself and is tracked in the OpenJDK project via an open ticket.

Second, Kubernetes does not yet support decreasing memory limits, even with in-place Pod Resize enabled. This is a known limitation documented in the enhancement proposal for memory limit decreases.

As a result, while in-place Pod Resize effectively addresses CPU-related startup spikes, memory resizing remains an open problem.

Final thoughts

In place Pod Resize gives a foundation for cool new features like StartupBoost and makes use of VPA more reliable. While important gaps remain, such as memory decrease support and scheduling race condition, this change represents a meaningful step forward.

For workloads with distinct startup and steady-state phases, Kubernetes is finally beginning to model reality more closely.

Contributing to Open Source: Why It Matters and How to Start

Alik Khilazhev — Thu, 18 Dec 2025 09:53:48 +0000

Whether you’re curious about open source or wondering how to make a meaningful impact, this post guides you through the process. You’ll learn why contributing is important, discover the different ways to get involved, and find practical steps to take your first contribution.

Why?

First of all, why should you contribute to open source?

Giving back

Everyone, from freelance engineers to Big Tech companies and even governments, uses Open Source Software (OSS). Some use it less, others more, but almost everyone depends on it in one way or another. Most of us are consumers of open source.

Contributing to OSS means giving something back. This is especially important given the many cases of projects (e.g nginx-ingress, external-secrets) being deprecated due to maintainer burnout, lack of community support, or overwhelming workloads.

It is true that some OSS projects are backed by large companies and maintained by engineers who are paid to work on them. However, the half of open source projects are still maintained by individuals in their spare time for free (source).

In this sense, contributing to OSS can be seen as a form of digital volunteering. Some companies (Criteo, Futurice) even offer paid volunteer time (VPTO) specifically for open-source contributions.

Learning

Another strong reason to contribute to open source is personal growth.

Every contribution becomes a learning opportunity because it places you inside a real, production-grade codebase rather than a controlled tutorial environment. You learn how projects are structured, how architectural decisions are made, how backward compatibility is maintained, and how trade-offs are handled in practice. Often this means working with unfamiliar tools, languages, or ecosystems, which naturally expands your technical range.

At the same time, open source strongly develops communication and collaboration skills. Issues and pull requests force you to articulate problems clearly, propose solutions in a way others can evaluate, and explain why a particular approach makes sense. Feedback from maintainers and contributors exposes you to different perspectives and constraints, requiring you to adapt, clarify, and sometimes rethink your ideas.

Because most collaboration happens asynchronously and in writing, you also improve your ability to communicate precisely and concisely. Over time, this structured, public collaboration sharpens how you discuss technical topics, handle reviews, and work effectively with distributed teams. These are the same skills required in modern engineering organizations, making open source a highly practical training ground.

Networking and professional reputation

Open source contribution naturally leads to networking, even if you are not actively trying to “network.” By participating in issues, code reviews, and pull requests, you start interacting with maintainers and contributors from different companies, countries, and levels of seniority. Over time, these repeated interactions build familiarity and trust. People begin to recognize your name, your areas of expertise, and the quality of your work.

Regular contributions can turn these lightweight interactions into professional relationships. Maintainers may invite you to collaborate more closely, grant you additional responsibilities, or even recommend you for roles on their teams. In many cases, job opportunities arise not from formal applications, but from someone already knowing how you work.

Another important, and often underestimated, benefit of open source contribution is visibility. Most professional work is hidden behind NDAs and internal repositories, making it difficult to demonstrate your real impact. Open source work, on the other hand, is public by default. Your commits, pull requests, discussions, and design decisions are all visible and attributable to you.

This public track record allows you to clearly show not only what you built or improved, but also how you collaborate, communicate, and respond to feedback. For recruiters and hiring managers, this is far more convincing than a list of skills on a résumé. In practice, open source contributions often function as a living portfolio and a long-term investment in your professional reputation.

How?

Now that you understand why contributing matters, let’s look at how to get started.

The Natural way

You might think that contributing to open source requires skills you do not have, a brilliant idea for a new library, or deep expertise in a specific domain. These beliefs often make OSS contribution feel unreachable.

That is not the case.

You do not need a revolutionary idea or special credentials. If you are an engineer who already writes code, you are capable of contributing.

Here is a simple approach: the next time you are solving a problem using an open source tool and notice that it does not work as expected (a bug) or lacks a feature you need, do not immediately abandon the tool. Use your skills, and an LLM if needed, to investigate and try to fix the issue.

If you succeed, open a pull request to the upstream repository. If you do not, create an issue and share your findings. That is still a contribution, and you will have learned something in the process.

Good first issue

If everything you use works perfectly and you do not notice any gaps, you can take a more deliberate approach.

Make a list of projects you like, use, or want to learn more about. Browse their open issues and look for ones labeled “good first issue” or similar. Pick something that matches your current skill level and try to tackle it.

If your list is short or you cannot find suitable issues, there are also curated lists of projects actively looking for contributors.

Summary

Open source is great, but keeping it that way requires people to contribute.
It is not hard or unreachable. Anyone can do it, and the community needs more people like you.
Start small, pick a project you love, and take your first step