实习期对Leader产生好感？聊聊职场边界与一道Lisp面试题

刚实习一个月，就对带你的Leader有了好感，这种剧情放在职场里，多少得掂量一下其中的风险。在你眼里，她可能是“娃娃脸又精明能干”的理想型，但在公司的流程和规则里，她首先是你汇报工作的上级，然后才是其他角色。你们目前连私下交流都寥寥无几，直接琢磨着加微信，恐怕连HR看到都得皱下眉头。

面对这种情况，评论区的意见通常分成两派。一派鼓励“喜欢就冲，年轻人别怂”；另一派则更现实，提醒“别把实习当恋爱综艺搞，小心工作先丢了”。我个人的看法更倾向于后者。这并不是说不能有好感，而是你现阶段产生的好感，很大概率掺杂了“职场滤镜”。对方的开朗、能干、善于带领团队，这些很大程度上是源于其职位所需的职业素养，你如果站得太近，容易误把这些专业表现当成独特的“心动信号”。

如果你真的想进一步了解对方，更稳妥的做法是先把本职工作干明白，创造一些线下正常沟通的机会，观察她对团队成员是否都如此，还是唯独对你有些特别。千万别一边周报都写不清楚，一边就急吼吼地把微信好友申请发过去，那样目的性太强，反而容易弄巧成拙。

聊完了职场小插曲，咱们切换一下频道。既然在云栈社区这样的技术交流平台，不如来看一道能让你冷静下来的面试题：Lisp 语法解析。

看到这种题，可千万别一上来就想用正则表达式硬怼。Lisp 语法解析 麻烦的地方不在于简单的加减乘除计算，而在于作用域的管理、表达式的嵌套，以及同名变量的覆盖。

你拿到的表达式，外层看起来可能像 (add 1 2) 这么简单，但稍微复杂一点就会变成这样：

(let x 2 (mult x (let x 3 y 4 (add x y))))

这时候，如果你脑子里没有清晰的“当前作用域”概念和“进入/退出子表达式”的递归流程，代码八成会越写越乱。对于这种题，我一般不会先去追求语法解析器有多优雅，而是先把解析顺序钉死：从左到右扫描字符串，遇到 ( 就进入递归解析，遇到变量先查找最近一层的作用域，遇到 let 就按对绑定变量。

核心的代码骨架可以这样搭建，先把入口和递归结构确立好：

class Solution {
    private String s;
    private int i;

    public int evaluate(String expression) {
        this.s = expression;
        this.i = 0;
        return eval(new java.util.HashMap<>());
    }

    private int eval(java.util.Map<String, java.util.Deque<Integer>> scope) {
        if (s.charAt(i) != '(') {
            return parseValue(scope);
        }

        i++; // 跳过 '('
        String op = parseToken();
        skipBlank();

        int ans;
        if ("add".equals(op)) {
            int a = eval(scope);
            skipBlank();
            int b = eval(scope);
            ans = a + b;
        } else if ("mult".equals(op)) {
            int a = eval(scope);
            skipBlank();
            int b = eval(scope);
            ans = a * b;
        } else {
            ans = evalLet(scope);
        }

        i++; // 跳过 ')'
        return ans;
    }
}

真正容易把人写崩的是 let 表达式的处理。很多人会图省事，把变量直接塞进 Map<String, Integer>，但一旦内层嵌套的 let 重复定义了同名变量，外层的值就会被覆盖且无法恢复。这里我更喜欢用 Map<String, Deque<Integer>> 结构，遇到同名变量就把新值压栈，退出当前作用域时再把栈顶的值弹掉。虽然代码看起来啰嗦了点，但逻辑清晰，非常稳当。

    private int evalLet(java.util.Map<String, java.util.Deque<Integer>> scope) {
        java.util.List<String> pushed = new java.util.ArrayList<>();
        while (true) {
            if (s.charAt(i) == '(' || s.charAt(i) == '-' || Character.isDigit(s.charAt(i))) {
                int v = eval(scope);
                rollback(scope, pushed);
                return v;
            }

            String name = parseToken();
            skipBlank();

            if (s.charAt(i) == ')') {
                int v = scope.get(name).peek();
                rollback(scope, pushed);
                return v;
            }

            int val = eval(scope);
            scope.computeIfAbsent(name, k -> new java.util.ArrayDeque<>()).push(val);
            pushed.add(name);
            skipBlank();
        }
    }

剩下的就是一些“体力活”：跳过空格、读取token、区分数字和变量名。这道题本质上不难，烦人的是细节特别琐碎，尤其有两个坑最为常见：

第一，let 表达式的最后一个位置不一定是“变量赋值”，它可能就是最终要返回的表达式本身。第二，变量查值时，必须遵循作用域链，查找最近一层定义的值，而不是全局最新的那次赋值。

所以说，这道题能不能做对，关键不在于你会不会写递归，而在于你能不能老老实实、清晰地维护作用域。代码写到这个份上，基本就成了。那些想靠字符串替换和正则走捷径的写法，在简单样例下或许能跑通，一旦嵌套层次变深，立刻就会原形毕露。

无论是处理微妙的职场关系，还是解决复杂的算法题，清晰的边界感和对核心规则的把握都是关键。你在实习或求职中还遇到过哪些让人纠结的场景或烧脑的题目？欢迎来云栈社区和大家一起聊聊。