I'm hiring for a frontline EM building the automation and trust layer for freight pricing, matching, onboarding, and settlement.Lead 1-3 teams (FTE + contractors), own delivery end-to-end, ~8 yrs exp typical. I expect everyone in my eng org (myself included!) to be technical and be able to help unblock the team, though your day-to-day wont be in the code.
Technical here means you can/will get into the code yourself and architecture reviews and maintain technical credibility with our junior to staff/principal level engineers. These are not player-coach roles, but these are frontline roles that need that technical capability.
Interesting problems: trust/fraud at marketplace scale; legacy-data-meets-modern-stack; and all kinds of problems that come with powering hundreds of thousands of load/shipment postings every day.
AI/LLM: We are leaned in, but still hold humans responsible for what they push and expect everyone to review and understand llm output before asking other humans to look at a thing.
Culture: I am deeply familiar with Google's project oxygen/aristotle and am building a culture where our teams can do great work with minimal bs.
Location: Must be local to one of our three locations (Seattle, Portland, Denver).
I'm hiring for both EM and Senior EM levels building the automation layer for freight pricing, matching, onboarding, and settlement. Lead 1-3 teams (FTE + contractors), own delivery end-to-end, ~8 yrs exp typical. I expect all managers to be technical and be able to help unblock the team, though your day-to-day wont be in the code.
Interesting problems: trust/fraud at marketplace scale; legacy-data-meets-modern-stack; and all kinds of problems that come with powering hundreds of billions of dollars worth of transactions every year.
AI/LLM: We are leaned in, but still hold humans responsible for what they push and expect everyone to review and understand llm output before asking other humans to look at a thing.
Culture: I am deeply familiar with Google's project oxygen/aristotle and am building a culture where our teams can do great work with minimal bs.
Location: Must be local to one of our three locations (Seattle, Portland, Denver)
In my experience, I have used coaches that don’t have more technical skill than me, but are able to provide insight, questions, and provoke me to think through my problems in ways I might not have otherwise.
I break things down into coaching vs training vs mentorship.
Training is when you need to learn a very specific skill from someone that knows more than you. A great example is learning how to drive - it requires training from someone who knows more than you.
Mentorship is when you need to grow more holistically and are learning from someone that is significantly more advanced in your chosen area of study than you. Usually this involves not just technical training, but also a mindset that you wish to learn. Examples of this are apprenticeships or when you seek out a mentor that you think has done well and wish to learn from.
Coaching is when someone may not have more technical skill than you, but is still able to help you improve by probing, prompting, reflecting, or observing. A great example are sport coaches, who are not necessarily more skilled than many of the players they coach.
These are loose and blurry definitions, but I hope it helps frame another perspective on coaching.
I was told they do have some slower paced roles (versus most of the "tip of the spear" work they do) during my last interview cycle, but it has been some time since that has occurred. Appreciate the recent ground truth. Does 18F still have a remote contingent of support/ancillary roles? It's always helpful to know who I can send where for those looking for work vs those needing work done.
Edit: Many thanks for taking the time to reply in depth.
If people are looking for hard (the hard mostly comes from the ambiguity of problem space and autonomous nature of our teams) impactful work, send em our way (USDS).
If they’re looking for impactful work, but not necessarily some of the things that make USDS “hard,” our partners are also great places to land.
There’s plenty of work for those that can do it though
Maybe it’s good, maybe it’s bad. A lot of anecdotes about “important” historical figures or institutions that use copy by hand as a method for learning.
I would have preferred citing actual research, not an appeal to historical methods.
Given that some of the conclusions that word for word copy may be less efficient than summarized copy[1], it may be a less efficient and less effective way of learning than going through a reading and summarizing every paragraph.
In my personal anecdata, writing a thing down is an important mechanism to note and recall facts I’ll find important later. I nearly never consult my notes. I’m even a terrible note taker, and always have been. I write things down in random places which normally I discard as they become clutter, just because the act of writing them is an additional point of recall when I might fail to recall otherwise. It doesn’t always serve me well, but it always serves me better than not making the note somewhere.
> I would have preferred citing actual research, not an appeal to historical methods. Given that some of the conclusions that word for word copy may be less efficient than summarized copy.
I can at least provide some links. [1] is my own research on giving students optional typing practice in a CS2 course. [2] is Mickie Chi's overview of the ICAP framework which categorizes learning activities based on their level of engagement (Interactive, Constructive, Active, Passive). Chi's work notes that higher modes of engagement provide more learning gains, or I > C > A > P.
Copying would be considered an Active exercise and theoretically would not give as much learning gains as a Self-Explanation exercise ("summarized copy", Constructive). However, much of the research into self-explanation shows that lower-performing students do not provide good summarizations/self-explanations. Thus, in my [1] work, I make the argument that for these students, completing a lower ICAP mode (typing practice) is a better use of their time. While it does not provide as much learning gain as a Constructive activity, it can still give students some gains that could potentially elevate them to a mental model that can successfully complete Self-Explanations.
> In your research area, is there a significant textbook or summary paper you would recommend that summarises current findings well?
It depends on what you're referring to by "research area". My focus is specific to novel CS exercises like typing exercises, Parsons Problems, coding problems, etc. In that regard I really like Teaching Tech Together [1] as a broad, here's a blanket review of CS education and its exercises. If you mean more generally to just CS Education, then Teaching Tech is still starting point I think, as it provides a nice literature review of the domain as well.
> What would you recommend to a complete amateur orienting themselves?
It'll depend (again) on what you mean here. If you mean learning about CS Education research, then the link above will be great. Then its about going down rabbit holes from the citations to read in more detail about those findings.
If you mean simply learning CS, the biggest recommendation I can make is carve out 1-4 hours a week (depending on your schedule) and commit to learning to code via MOOCs, tutorials, videos etc. Find a CS1 syllabus from a university that has a schedule on it and follow that. A lot of learning can be traced back to "time on task". Ignoring the recent HN post about how years of experience doesn't equal most skilled coders, that article is looking at what research calls "experts" vs. "novices" (beginners). We know spaced repetition works, we know cramming (trying to learn it all immediately) doesn't. Following the syllabus' schedule will space out your learning, force you to recall the information, and produce better learning in the long run.
The idea is to make it a part of your weekly "routine" to the point where if you DON'T do it, you feel weird. For example, I've trained martial arts for 15+ years. Somewhere in that time, I'm so used to going to train that when I take nights off, its weird because I'm just USED to training. Even my body wakes up cause its used to needing adrenaline. That needs to be a part of any learning process.
Oh I've definitely figured out the trick to learning CS, tékhnē.
No worries there.
I'm simply curious about the state of the art of the pedagogy.
CS education is a fascinating situation. You have an interaction of strong mathematical, socioeconomic, and generally academic backgrounds, and often the complete opposite studying it. Plus very little institutional knowledge around pedagogy or anything else relative to almost all other fields of academia. And yet, there are all sorts of interesting factoids around the place, like https://www.youtube.com/watch?v=7J-wCHDJYmo.
I don't pretend get how it all fits together.
Thank you very much, Teach Together looks like the perfect starting point, and I can follow the citation breadcrumgbs from there.
"Way of learning" is a very broad term, and the two ways may be good for different aspects of it.
Verbatim copying is good for bringing your attention to the material, it helps you notice more, and doesn't let you mind wander. While summarizing is good for cementing what you've noticed and learned.
For example, if I try to copy part of text I see the writing techniques used there a lot better. I don't see how summarizing can give me the same effect.
I'm almost ready to try both techniques simultaneously, although it seems like an overkill, so much writing.
At the beginning of diving into a topic area or when I want to go very deep on a subject.
Books tend to have good comprehensive overviews of an area/technology, whereas most online tutorials are very shallow, even if more current.
On the flip side, when I need /deep/ understanding it’s almost always a combination of a book on the topic to fill in holes I missed, the docs, and live repos if available.
If it’s just for day to day use, or a technology I’m only using in passing - no.
I do vet the authors though. A lot of trash is published.
I'm hiring for a frontline EM building the automation and trust layer for freight pricing, matching, onboarding, and settlement.Lead 1-3 teams (FTE + contractors), own delivery end-to-end, ~8 yrs exp typical. I expect everyone in my eng org (myself included!) to be technical and be able to help unblock the team, though your day-to-day wont be in the code.
Technical here means you can/will get into the code yourself and architecture reviews and maintain technical credibility with our junior to staff/principal level engineers. These are not player-coach roles, but these are frontline roles that need that technical capability.
Interesting problems: trust/fraud at marketplace scale; legacy-data-meets-modern-stack; and all kinds of problems that come with powering hundreds of thousands of load/shipment postings every day.
AI/LLM: We are leaned in, but still hold humans responsible for what they push and expect everyone to review and understand llm output before asking other humans to look at a thing.
Culture: I am deeply familiar with Google's project oxygen/aristotle and am building a culture where our teams can do great work with minimal bs.
Location: Must be local to one of our three locations (Seattle, Portland, Denver).
Primary Tech: Node/TS, React, GraphQL, Kafka/redpanda, k8s, AWS, etc
https://careers.dat.com/jobs/?gh_jid=6139594004
Reach out directly at <fname>.<lname>+hn@dat.com; I am the hiring manager for these roles. I'll junk anything that smells of AI.
My profile and background: https://www.linkedin.com/in/kelvin-luu/
reply